Belajar GitHub Actions - Environment Protection Rules & Approval Gateways

#Pendahuluan

Di episode 16 kita membangun gerbang kualitas dan keamanan: test, coverage, lint, SonarQube, CodeQL, dan Dependabot. Semua itu melindungi kode, tapi belum melindungi lingkungan deployment. Siapa yang bisa men-deploy ke production? Kapan boleh? Bagaimana kalau kredensial production dipakai oleh workflow dari branch developer? Di episode ini kita menjawab pertanyaan-pertanyaan itu dengan Environment Protection Rules.

Di episode ini kita membahas:

Manajemen environment development, staging, dan production di GitHub.
Protection rules: required reviewers, wait timer, environment secrets, dan branch binding.
Workflow deploy production dengan approval gate.

#Apa itu Environment di GitHub?

Environment adalah segmen deployment yang diberi nama: development, staging, production. Setiap environment bisa membawa secret dan protection rules sendiri. Analoginya seperti pintu di gedung bertingkat — lantai bawah (development) bebas dilalui, lantai atas (production) butuh badge khusus dan disertai petugas.

Environment dibuat lewat repository Settings → Environments. Setiap environment bisa diisi:

Environment secrets — kredensial khusus yang hanya tersedia untuk job yang men-deploy environment itu.
Protection rules — siapa yang boleh deploy dan bagaimana caranya.
Deployment branches — branch mana saja yang diizinkan men-deploy ke environment tersebut.

#Protection Rules: Menambahkan Manusia ke Dalam Pipeline

#Required Reviewers — Gate Persetujuan Manual

Ini adalah jantung approval gateway. Ketika diaktifkan, GitHub menghentikan job deployment dan menampilkan notifikasi ke reviewer yang ditunjuk. Deployment baru berjalan setelah reviewer menyetujui. Halaman Deployment di UI GitHub menjadi pusat kendali: melihat antrean, menyetujui, atau menolak.

Note

Required reviewers berbeda dari branch protection. Branch protection mengontrol siapa yang boleh merge kode; required reviewers mengontrol siapa yang boleh men-deploy. Keduanya bisa — dan sebaiknya — dipakai bersamaan.

#Wait Timer — Delay Otomatis

Wait timer menunda eksekusi deployment selama N menit setelah job disiapkan. Gunanya memberi jendela observasi setelah staging dideploy, atau memberi waktu bagi developer untuk membatalkan jika ada yang mencurigakan.

#Environment Secrets & Branch Binding

Environment secrets menimpa repository secrets untuk job yang men-deploy environment itu. Misalnya token DEPLOY_TOKEN di repository level bernilai token development, sementara di environment production bernilai token berhak lebih besar. Dengan branch binding, workflow dari branch selain main tidak bisa men-deploy ke production, apa pun yang tertulis di file YAML.

Warning

Protection rules bukan pengganti security. Kalau repository bersifat public dan memakai self-hosted runner, siapa pun yang bisa membuat pull request bisa menjalankan kode di runner kalian. Selalu pasang protection rules AND branch protection, dan jangan pernah memakai self-hosted runner di repository public.

#Workflow Deploy Production dengan Environment & Gate

Inilah bagian inti. Job men-deklarasikan environment lewat key environment. Saat GitHub melihat job dengan environment: production, ia otomatis memeriksa protection rules environment itu — termasuk menunggu persetujuan reviewer:

deploy-production.yml - environment & approval gate

name: Deploy to Production
 
on:
  workflow_dispatch:
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    concurrency:
      group: production
      cancel-in-progress: false
    steps:
      - name: Checkout kode
        uses: actions/checkout@v4
 
      - name: Deploy production
        run: ./scripts/deploy.sh
        env:
          PRODUCTION_API_KEY: ${{ secrets.PRODUCTION_API_KEY }}

Yang perlu diperhatikan:

concurrency dengan cancel-in-progress: false memastikan hanya satu deployment production berjalan dalam satu waktu — yang baru mengantre, bukan membatalkan yang lama.
Secret PRODUCTION_API_KEY diambil dari environment production, bukan dari repository level. Kalau tidak ada di environment itu, job gagal dengan pesan yang jelas.
Dengan required reviewers aktif, job deploy akan berstatus "waiting" sebelum step mana pun dijalankan.

#Strategi Perlindungan Berlapis

Untuk production-grade, gabungkan semua perlindungan dalam satu lapisan:

Lapisan	Mengontrol	Contoh
Branch protection	Merge kode	Require status checks, 2 approvals
Deployment branches	Dari branch mana deploy	Hanya main
Required reviewers	Siapa menyetujui deploy	Lead Engineer
Wait timer	Kapan deploy berjalan	5 menit setelah staging
Concurrency	Berapa deploy berjalan	Maksimal 1 per environment
Environment secrets	Kredensial per environment	Token terpisah staging vs prod

Kalau production adalah lingkungan yang mahal (downtime = uang), lapisan ini mengubah pipeline dari "siapa pun bisa deploy" menjadi "peristiwa teraudit dengan persetujuan eksplisit".

Tip

Mulailah dengan environment staging tanpa required reviewers supaya alur tetap cepat, lalu aktifkan reviewer hanya untuk production. Developer tetap produktif sementara production dilindungi.

#Penutup

Di episode ini kita membahas environment protection rules & approval gateways:

Environment memisahkan secret, branch, dan aturan per segmen deployment.
Required reviewers membuat job deployment menunggu persetujuan manual.
Wait timer memberi jendela waktu observasi sebelum deployment berjalan.
Environment secrets dan branch binding membatasi siapa yang boleh deploy ke mana.
Workflow dengan environment: production plus concurrency memastikan rilis berjalan terkendali dan hanya satu dalam satu waktu.

Pipeline yang terkontrol adalah fondasi rilis yang stabil. Di episode 18 kita mengotomasi release management & semantic versioning — menamai versi dari commit message dan membuat GitHub Release beserta changelog tanpa sentuhan manual. Sampai jumpa!