GitLab CI/CD: Variabel Dinamis Lintas Environment

Mengelola Variabel CI/CD: Solusi Cerdas untuk Multi-Environtment

Pernahkah lo merasa pusing saat harus mengatur konfigurasi aplikasi yang berbeda untuk setiap environtment? Dari development yang santai, staging yang mirip production, hingga production yang kritis, setiap environtment butuh setelan unik. Gue ingat betul, dulu rasanya seperti juggling bola saat harus memastikan BASE_URL atau API_KEY engga tertukar antara dev.myapp.com dan prod.myapp.com. Sedikit saja salah ketik, bisa-bisa data test masuk ke production atau, yang lebih parah, aplikasi production malah terhubung ke database staging yang kosong. Kekhawatiran ini, dan insiden kecil yang tak terhitung jumlahnya, mendorong gue untuk mencari cara yang lebih aman, rapi, dan otomatis.

Di sinilah GitLab CI/CD datang sebagai penyelamat. Khususnya, fitur pengelolaan variabel dengan environment scope yang memungkinkan kita mendefinisikan variabel dengan nama yang sama, namun dengan nilai berbeda, tergantung di environtment mana pipeline sedang berjalan. Ini bukan sekadar trik, melainkan praktik fundamental dalam mencapai alur kerja DevOps yang mulus dan bebas drama. Artikel ini akan membahas bagaimana kita bisa memanfaatkan kekuatan ini, memastikan setiap deployment lo tepat sasaran tanpa perlu khawatir salah konfigurasi lagi. Siap menghilangkan pusing kepala lo? Ayo kita selami lebih dalam!

Mengapa Variabel Lintas Environtment Begitu Penting?

Dalam dunia development software modern, kita jarang (atau seharusnya engga pernah) memiliki satu environtment saja. Aplikasi yang kita bangun biasanya melalui beberapa tahap:

• Development: Tempat developer bermain-main, mencoba fitur baru, dan seringkali menggunakan data dummy.
• Staging: Environtment yang dirancang semirip mungkin dengan production untuk pengujian akhir sebelum rilis. Di sinilah QA melakukan tes regresi dan UAT.
• Production: Environtment live yang diakses oleh pengguna akhir. Kesalahan di sini bisa berdampak besar.

Setiap environtment ini memiliki kebutuhan konfigurasi yang berbeda. Misalnya:

• URL API: api.dev.example.com, api.staging.example.com, api.prod.example.com
• Kunci API Eksternal: DEV_API_KEY, STAGING_API_KEY, PROD_API_KEY
• Database Credentials: DB_USER_DEV, DB_USER_STAGING, DB_USER_PROD
• Setelan Fitur: Fitur tertentu mungkin diaktifkan di development untuk pengujian, tetapi dinonaktifkan di production.

Secara tradisional, mengelola ini bisa jadi mimpi buruk. lo mungkin tergoda untuk mengubah file konfigurasi secara manual sebelum setiap deployment, tetapi ini sangat rawan kesalahan. Atau, menggunakan if-else statement yang rumit di dalam kode lo, yang membuat kode menjadi kotor dan sulit dipertahankan.

Solusinya? Gunakan variabel environtment yang dapat diatur secara terpusat oleh platform CI/CD lo, dalam kasus ini, GitLab. Dengan kemampuan untuk memberikan nilai variabel yang berbeda berdasarkan “lingkup environtment” atau environment scope, kita dapat mencapai otomatisasi yang tinggi dan menghilangkan human error.

Memulai: Mendefinisikan Environment di GitLab

Sebelum kita bisa mulai bermain-main dengan variabel, langkah pertama adalah memastikan GitLab tau apa saja “environtment” yang kita miliki. Ini dilakukan melalui menu Deployments > Environments di GitLab project lo. Seperti yang terlihat dari kasus yang diberikan, lo sudah mendefinisikan environtment staging.

Pengaturan environtment GitLab menampilkan environtment ‘staging’ dengan URL eksternal.

Mendefinisikan environment di sini bukan hanya formalitas. Ini memungkinkan GitLab untuk:

• Melacak deployment ke environment tersebut.
• Menyediakan tautan cepat ke URL eksternal environment.
• Yang terpenting, menjadi dasar bagi environment scope variabel CI/CD kita.

Rahasia Dapur: Mengatur Variabel dengan Environment Scope

Ini adalah inti dari pembahasan kita. Di GitLab, lo dapat membuat variabel dengan nama yang sama, tetapi dengan nilai yang berbeda, dengan menetapkan environment scope yang spesifik. Mari kita ambil contoh kasus yang kita bahas: lo punya * (sebagai default/main) dan staging.

1. Variabel untuk Environtment Default (* atau All (default)):

   • Buka Settings > CI/CD > Variables.
   • Klik Add variable.
   • Isi Key (misalnya, APP_API_BASE_URL).
   • Isi Value (misalnya, https://api.prod.mycompany.com).
   • Biarkan Environment scope sebagai All (default) atau pilih *.
   • Sangat disarankan untuk centang Protect variable (jika ini untuk production dan berisi sensitif data) dan Mask variable agar nilai engga terlihat di log.
   • Klik Add variable.

   Antarmuka pembuatan variabel GitLab CI/CD, menampilkan opsi untuk key, value, type, environtment scope, dan flag.

   Pengalaman Pribadi: Dulu, gue pernah engga centang Mask variable untuk API_KEY di environment development. Alhasil, key tersebut terekspos di log build, untungnya hanya internal. Kejadian itu menjadi pengingat keras betapa pentingnya Mask variable, terutama untuk kredensial.

2. Variabel untuk Environtment staging:

   • Klik Add variable lagi.
   • Isi Key yang sama persis dengan variabel sebelumnya (APP_API_BASE_URL).
   • Isi Value yang berbeda, yang sesuai untuk environtment staging lo (misalnya, https://api.staging.mycompany.com).
   • Pilih Environment scope sebagai staging.
   • Sesuaikan Protect variable dan Mask variable sesuai kebutuhan.
   • Klik Add variable.

Sekarang, lo memiliki dua variabel dengan nama APP_API_BASE_URL, tetapi dengan nilai yang berbeda untuk lingkup yang berbeda. GitLab akan cerdas memilih nilai yang sesuai.

Menghubungkan Job CI/CD dengan Environment

Agar GitLab tau kapan harus menggunakan variabel staging atau *, lo perlu memberi tau job di .gitlab-ci.yml lo ke environtment mana job tersebut deploy. Ini dilakukan dengan menambahkan blok environment pada job yang relevan.

Mari kita asumsikan lo memiliki branch main untuk production (secara implisit di sini, menggunakan scope *) dan branch feature/file-manager-media-s3 untuk staging.

# .gitlab-ci.yml

stages:
  - build
  - deploy

build_app:
  stage: build
  script:
    - echo "Building application..."
    - npm ci
    - npm run build

deploy_to_staging:
  stage: deploy
  script:
    - echo "Deploying to Staging Environment..."
    - echo "Current API Base URL for Staging: $APP_API_BASE_URL" # Ini akan otomatis mengambil nilai 'staging'
    # Perintah deployment lo ke server staging
    - rsync -avz --delete public/ user@your-staging-server:/var/www/html/staging/
  environment:
    name: staging
    url: [https://api.prod.mycompany.com](https://api.prod.mycompany.com) # URL yang lo definisikan di GitLab UI
  only: # Menggunakan 'only' untuk membatasi eksekusi job
    - feature/file-manager-media-s3 # Job ini hanya berjalan untuk branch ini

deploy_to_production:
  stage: deploy
  script:
    - echo "Deploying to Production Environment..."
    - echo "Current API Base URL for Production: $APP_API_BASE_URL" # Ini akan otomatis mengambil nilai '*'
    # Perintah deployment lo ke server production
    - rsync -avz --delete public/ user@your-production-server:/var/www/html/production/
  environment:
    name: production # lo juga perlu membuat environment 'production' di UI GitLab
    url: [https://prod.mycompany.com](https://prod.mycompany.com)
  only:
    - main # Job ini hanya berjalan untuk branch main

Bagaimana GitLab Memilih Variabel?

Prioritas pemilihan variabel oleh GitLab adalah sebagai berikut:

1. Environment Spesifik: Jika job memiliki blok environment dan nama environment cocok dengan scope variabel (name: staging di job akan mencari variabel dengan Environment scope: staging), maka variabel tersebut akan digunakan.
2. Wildcard (*): Jika engga ada variabel dengan scope yang cocok persis dengan nama environment job, GitLab akan mencari variabel dengan scope * (All/default).

Ini berarti, ketika pipeline berjalan di branch feature/file-manager-media-s3 dan job deploy_to_staging dieksekusi, GitLab akan melihat environment: name: staging. Kemudian, ia akan mencari variabel APP_API_BASE_URL dengan scope staging dan menggunakannya.

Sebaliknya, saat pipeline berjalan di branch main dan job deploy_to_production dieksekusi, GitLab akan mencari variabel APP_API_BASE_URL dengan scope production. Jika engga ada (dan jika production engga memiliki variabel APP_API_BASE_URL spesifik), maka GitLab akan jatuh kembali ke variabel APP_API_BASE_URL dengan scope *. Ini memberikan fleksibilitas luar biasa.

only vs. rules: Pilihan dalam Mengontrol Job

Pada kasus di atas, lo menggunakan only: - feature/file-manager-media-s3. Ini adalah cara yang valid dan sering digunakan untuk membatasi eksekusi job ke branch tertentu.

• only: Sederhana dan efektif untuk skenario dasar pembatasan branch. Job hanya akan dijalankan jika commit berasal dari branch yang terdaftar.
• rules: GitLab merekomendasikan rules untuk kontrol yang lebih canggih. lo dapat menggabungkan berbagai kondisi (if, changes, exists) dan secara eksplisit menentukan when (kapan job dijalankan, misal on_success, manual, always, never).

Sebagai contoh, jika lo ingin job deploy_to_staging hanya berjalan pada feature/file-manager-media-s3 dan hanya jika ada perubahan pada folder src/ project lo, rules akan lebih cocok:

deploy_to_staging:
    stage: deploy
    # ...
    rules:
        - if: $CI_COMMIT_BRANCH == "feature/file-manager-media-s3"
          changes:
              - src/**/*
          when: on_success

Namun, untuk kebutuhan lo saat ini, only sudah lebih dari cukup dan akan bekerja dengan sempurna.

Kesimpulan: Otomatisasi yang Membebaskan Developer

Mengelola variabel environtment di GitLab CI/CD dengan environment scope adalah salah satu praktik terbaik yang dapat lo adopsi untuk menyederhanakan alur deployment lo. Ini mengurangi risiko kesalahan manual, membuat konfigurasi lebih transparan, dan memungkinkan tim lo fokus pada pengembangan fitur daripada pusing dengan setelan environtment. Gue sendiri merasakan lega yang luar biasa setelah mengimplementasikan ini di berbagai proyek. Rasanya seperti memiliki asisten pribadi yang selalu tau konfigurasi mana yang tepat untuk setiap tahap deployment.

Dengan kombinasi penyiapan environment yang tepat di GitLab UI, definisi variabel dengan scope yang sesuai, dan konfigurasi .gitlab-ci.yml yang cerdas, lo akan memiliki sistem deployment yang kuat, otomatis, dan tahan banting. Jadi, engga ada lagi kekhawatiran tentang prod yang terhubung ke dev! Good luck dan semoga pipeline lo selalu hijau!