Belajar GitLab CI/CD - Environments, Deployments & Manual Approval Gates

#Pendahuluan

Di episode 13 sebelumnya kita membahas cara pipeline mengotentikasi diri ke cloud dengan OIDC tanpa menyimpan kredensial permanen. Sekarang pertanyaannya beralih: ke mana kredensial sementara itu dipakai untuk men-deploy? Di sinilah konsep environment masuk.

Bayangkan kalian memantau tim pengelolaan gedung tanpa sistem kunci yang jelas: siapa saja boleh masuk, kapan pun, tanpa ada catatan. Ketika ada masalah di lantai 3, tidak ada yang tahu kapan perubahan terakhir dilakukan dan oleh siapa. Deployment software menghadapi masalah yang sama. Tanpa sistem pelacakan, "siapa yang men-deploy versi apa ke mana" adalah misteri — dan ketika produksi down, misteri itu sangat mahal.

GitLab menyelesaikan ini dengan konsep Environment dan Deployment: setiap target yang menerima hasil build (staging, production, review app) dideklarasikan secara eksplisit, dan setiap eksekusi deployment dicatat sebagai entri deployment yang bisa dilacak di UI. Episode ini membahas deklarasi environment, approval gate manual untuk produksi, protected environments, serta Review Apps — environment dinamis yang hidup dan mati mengikuti siklus hidup merge request.

#Pembahasan Utama

#Konsep Environment: Target Deployment yang Dideklarasikan

Environment adalah target tempat aplikasi di-deploy — bisa staging, production, atau environment per-branch. Ketika sebuah job mendeklarasikan environment, GitLab menautkan hasil pipeline ke environment tersebut dan mencatatnya sebagai deployment baru.

deploy-staging:
  stage: deploy
  environment:
    name: staging
    url: https://staging.myapp.com
  script:
    - echo "Deploy ke staging"

Dua atribut yang paling penting:

1. name — identitas environment. Convention yang umum: staging, production, atau review/<nama-branch>.
2. url — alamat aplikasi. Nilai ini membuat GitLab menampilkan tombol untuk membuka environment langsung dari pipeline dan merge request.

Begitu job ini berhasil, sebuah deployment tercatat — GitLab tahu versi mana (berdasarkan SHA commit) sedang aktif di environment tersebut.

#Melacak Riwayat Deployment di UI GitLab

Semua deployment yang tercatat bisa ditelusuri melalui menu Operate → Environments (atau Deployments) di sidebar project. Halaman ini menampilkan:

• Daftar environment beserta status terkini — apakah deployment terakhir berhasil, sedang berjalan, atau gagal.
• Riwayat deployment per environment: kapan, di commit mana, oleh pipeline mana, dan hasilnya.
• Tombol rollback untuk mengembalikan environment ke deployment sebelumnya.

Rollback ini bukan sekadar fitur yang nyaman — ia adalah salah satu alasan terkuat untuk selalu mendeklarasikan environment di semua job deployment. Ketika production bermasalah, tim cukup klik rollback ke deployment terakhir yang sehat, bukan memutar ulang pipeline dari awal.

#Manual Approval Gates: when: manual

Deployment ke produksi idealnya bukan keputusan otomatis. GitLab menyediakan approval gate dengan keyword when: manual: job tidak berjalan sampai seorang manusia meng-klik tombol play di UI.

deploy-production:
  stage: deploy
  environment:
    name: production
    url: https://myapp.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
  script:
    - echo "Deploy ke produksi"

Kombinasi rules + when: manual adalah pola modern yang direkomendasikan: job hanya muncul di pipeline branch main, dan hanya dijalankan ketika manusia mengkliknya. Job manual menahan pipeline di stage tersebut — stage selanjutnya tidak berjalan sampai job ini dieksekusi atau di-skip.

#Protected Environments: Membatasi Siapa yang Boleh Deploy

Protected environments menambahkan lapisan kontrol akses pada environment. Dengan mengaktifkannya, GitLab hanya mengizinkan pengguna dengan peran tertentu — misalnya Maintainers atau Release Manager — untuk mengeksekusi job deployment ke environment tersebut. Environment juga bisa dibatasi untuk branch tertentu, misalnya hanya main.

deploy-production:
  stage: deploy
  environment:
    name: production
    url: https://myapp.com
    protected: true
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

Pengaturan who can deploy dilakukan di Settings → CI/CD → Protected environments: pilih environment (misal production), lalu tentukan peran yang boleh deploy dan yang boleh approve. Dengan begitu, approval gate bukan sekadar tombol — ia hanya bisa diklik oleh orang yang berwenang.

#Dynamic Environments & Review Apps

Salah satu fitur paling produktif di GitLab adalah Review Apps: setiap merge request otomatis mendapat environment sementara (spin-up) untuk aplikasi versi fitur tersebut, sehingga reviewer bisa mencoba perubahan secara nyata sebelum menyetujui MR.

deploy-review:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_COMMIT_REF_SLUG.review.myapp.com
    on_stop: stop-review
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - echo "Deploy review app untuk branch ini"
 
stop-review:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual
  script:
    - echo "Hentikan review app"

Perhatikan polanya:

• Nama environment dibuat dinamis dengan $CI_COMMIT_REF_SLUG — slug dari nama branch, sehingga setiap branch punya environment unik.
• Job deploy-review memakai on_stop: stop-review — menunjuk job yang bertugas menghentikan environment.
• Job stop-review memakai action: stop, yang menandai environment sebagai stopped ketika dijalankan.

#Kesalahan Umum dalam Mengelola Environments

#Penutup

Pada episode ini kita telah membahas konsep environment sebagai target deployment yang dideklarasikan dengan environment: name dan url; pelacakan riwayat deployment melalui menu Deployments dan fitur rollback di UI GitLab; manual approval gates dengan when: manual yang menahan deployment sampai diklik manusia; protected environments untuk membatasi eksekusi hanya pada peran tertentu; serta Review Apps dengan on_stop dan action: stop untuk environment dinamis yang hidup dan mati mengikuti merge request.

Inti dari episode ini: deployment yang tidak terlacak adalah risiko; deployment yang terlacak adalah aset. Dengan environment yang terkelola, tim tahu kapan, oleh siapa, dan ke mana setiap versi aplikasi dikirim — dan bisa menariknya kembali kapan pun.

Di episode 15 selanjutnya kita menutup FASE 6 dengan hands-on paling nyata: Continuous Deployment ke Linux Server via SSH dan Ansible — menyiapkan kunci SSH, ssh-agent dan ssh-keyscan di pipeline, sinkronisasi file dengan rsync, hingga otomasi deployment penuh dengan Ansible playbook. Sampai jumpa!