Berhenti Memperlakukan Governance sebagai Sistem Tiket Terpisah

Anda baru saja menyelesaikan sebuah fitur. Kode sudah dibangun, pengujian hijau, dan deployment di staging terlihat sehat. Sekarang apa? Di banyak tim, langkah selanjutnya adalah membuka tiket, mengirim email ke change advisory board, dan menunggu. Mungkin berjam-jam, mungkin berhari-hari. Pipeline menganggur sementara orang-orang mengejar persetujuan melalui sistem yang sepenuhnya terpisah.

Pemisahan antara pekerjaan teknis dan governance ini menciptakan gesekan. Developer harus berpindah konteks dari alat mereka. Pemberi persetujuan meninjau perubahan tanpa melihat hasil pengujian atau riwayat deployment. Jejak audit tersebar di utas email, komentar tiket, dan pesan chat. Semua orang merasa prosesnya lambat, tetapi tidak ada yang ingin menghilangkan pemeriksaan sepenuhnya.

Solusinya bukan menghilangkan governance. Solusinya adalah menanamkan governance langsung ke dalam pipeline tempat pekerjaan sudah dilakukan.

Langkah Persetujuan Manual: Sederhana dan Mudah Diaudit

Integrasi yang paling sederhana adalah gerbang persetujuan manual di pipeline Anda. Setelah build otomatis dan pengujian lulus di staging, pipeline berhenti. Pipeline menunggu manusia untuk meninjau bukti dan mengklik setujui sebelum melanjutkan ke produksi.

Diagram berikut membandingkan pendekatan lama dengan yang baru:

flowchart TD subgraph Old[Old: Sistem Tiket Terpisah] A[Kode siap] --> B[Buka tiket di sistem eksternal] B --> C[Tunggu review CAB] C --> D[Deploy manual] end subgraph New[New: Gerbang Persetujuan di Pipeline] E[Kode siap] --> F[Pengujian otomatis lulus] F --> G[Pipeline berhenti untuk persetujuan] G --> H[Peninjau melihat hasil tes & diff] H --> I[Setujui / Tolak] I --> J[Deploy ke produksi] end Old -.->|Lebih banyak gesekan| New

Pola ini bekerja dengan baik untuk perubahan normal yang membutuhkan penilaian manusia tetapi tidak memerlukan rapat CAB penuh. Peninjau dapat melihat hasil pengujian, diff, dan status deployment semuanya di satu tempat. Mereka tidak perlu membuka tiket terpisah atau mencari konteks di log chat.

Berikut adalah contoh minimal GitHub Actions yang menjeda pipeline untuk persetujuan manual sebelum mendeploy ke produksi:

name: Deploy to Production

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://example.com
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: make test
      - name: Deploy
        run: make deploy

Ketika workflow ini berjalan, GitHub Actions membuat deployment ke environment production. Jika environment tersebut memerlukan peninjau, pipeline berhenti dan menunggu persetujuan sebelum mengeksekusi langkah Deploy. Peninjau melihat commit, hasil pengujian, dan diff di antarmuka GitHub.

Detail pentingnya adalah langkah persetujuan harus mencatat siapa yang menyetujui, kapan, dan apa yang disetujui. Ini menjadi jejak audit. Alat seperti GitLab CI/CD, Jenkins, dan GitHub Actions semuanya mendukung ini secara native. Anda mengonfigurasi peran mana yang dapat menyetujui deployment produksi -- biasanya engineer senior atau tech lead -- dan pipeline akan menegakkannya.

Tetapi persetujuan manual bukanlah jawaban yang tepat untuk setiap perubahan. Jika setiap pull request membutuhkan manusia untuk mengklik tombol, Anda memperlambat pembaruan berisiko rendah yang seharusnya mengalir secara otomatis.

Policy-as-Code: Biarkan Pipeline yang Memutuskan

Untuk perubahan standar dengan risiko yang dapat diprediksi, persetujuan manual menjadi hambatan. Di sinilah policy-as-code berperan. Alih-alih menulis aturan governance dalam dokumen yang harus diingat orang, Anda menulisnya sebagai kode yang dievaluasi pipeline secara otomatis.

Aturan policy-as-code mungkin mengatakan: "Perubahan yang hanya menyentuh file konfigurasi frontend dapat dideploy ke produksi tanpa review manusia, selama semua pengujian lulus." Atau: "Perubahan apa pun yang menambahkan kolom ke tabel database harus mendapatkan persetujuan dari DBA sebelum dilanjutkan."

Anda menyimpan aturan-aturan ini dalam file di dalam repositori Anda, seperti kode aplikasi. Pipeline membaca aturan, mengevaluasi perubahan saat ini terhadap aturan tersebut, dan memutuskan apakah akan berhenti untuk review atau melanjutkan secara otomatis. Jika suatu aturan dilanggar, pipeline gagal dengan pesan yang jelas: "Perubahan ini menambahkan kolom ke tabel users, tetapi tidak ada persetujuan DBA yang ditemukan."

Tim tidak perlu menebak-nebak apakah perubahan mereka aman. Pipeline memberi tahu mereka, dan menegakkan aturan secara konsisten setiap saat.

Menggabungkan Kedua Pendekatan

Langkah persetujuan manual dan policy-as-code tidak saling eksklusif. Keduanya bekerja paling baik bersama-sama. Policy-as-code menangani keputusan rutin secara otomatis. Gerbang persetujuan manual menangkap perubahan yang membutuhkan penilaian manusia.

Misalnya, pipeline Anda mungkin memiliki aturan-aturan ini:

  • Perubahan pada dokumentasi atau aset statis: deploy otomatis setelah pengujian lulus.
  • Perubahan pada kode aplikasi dengan cakupan pengujian penuh dan tanpa migrasi database: deploy otomatis setelah validasi staging.
  • Perubahan yang memodifikasi skema database: berhenti dan memerlukan persetujuan DBA.
  • Perubahan pada logika autentikasi atau pembayaran: berhenti dan memerlukan persetujuan tim keamanan.
  • Perubahan selama periode freeze (akhir kuartal, musim liburan): berhenti dan memerlukan persetujuan engineering manager.

Pipeline mengevaluasi perubahan, menerapkan aturan yang cocok, dan melanjutkan atau berhenti. Tim tidak perlu mengingat perubahan mana yang membutuhkan persetujuan apa. Pipeline yang tahu.

Mengapa Ini Mempermudah Audit

Ketika governance hidup di dalam pipeline, audit menjadi mudah. Auditor tidak perlu mengumpulkan tangkapan layar dari utas email atau mencari melalui komentar tiket. Mereka melihat riwayat pipeline untuk perubahan tertentu. Catatan menunjukkan:

  • Siapa yang membuat perubahan
  • Apa yang diubah
  • Pengujian mana yang dijalankan dan apakah lulus
  • Kebijakan mana yang dievaluasi
  • Siapa yang menyetujui perubahan dan kapan
  • Kapan perubahan mencapai produksi

Semuanya ada di satu tempat. Setiap keputusan diberi stempel waktu dan atribusi. Tidak ada celah antara apa yang diklaim tim telah terjadi dan apa yang dicatat pipeline.

Daftar Periksa Praktis untuk Mengintegrasikan Governance ke dalam Pipeline Anda

Sebelum Anda mulai menambahkan gerbang persetujuan dan aturan kebijakan, jalankan daftar periksa ini dengan tim Anda:

  • Daftar jenis perubahan yang dibuat tim Anda (konfigurasi, skema, kode aplikasi, infrastruktur, dll.)
  • Untuk setiap jenis, tentukan tingkat risikonya: rendah, sedang, atau tinggi
  • Untuk perubahan berisiko rendah, tulis aturan policy-as-code yang memungkinkan deployment otomatis
  • Untuk perubahan berisiko sedang, tambahkan langkah persetujuan manual dengan kriteria persetujuan yang jelas
  • Untuk perubahan berisiko tinggi, perlukan beberapa persetujuan atau proses pengecualian yang terdokumentasi
  • Konfigurasikan siapa yang dapat menyetujui setiap tingkat perubahan di alat pipeline Anda
  • Uji pipeline dengan perubahan nyata untuk memastikan gerbang berfungsi seperti yang diharapkan
  • Tinjau jejak audit setelah beberapa deployment pertama untuk memverifikasi kelengkapan

Governance Bukanlah Tambahan

Ketika governance terintegrasi ke dalam pipeline, ia tidak lagi terasa seperti proses tambahan yang memperlambat semua orang. Ia menjadi bagian dari alur normal, seperti menjalankan pengujian atau membangun artefak. Tim bergerak cepat untuk perubahan berisiko rendah dan mendapatkan tingkat review yang tepat untuk perubahan berisiko tinggi. Jejak audit otomatis dan lengkap.

Lain kali seseorang meminta persetujuan, jangan buka tiket. Buat pipeline yang memintanya.