Saat Pipeline Anda yang Memutuskan Siapa yang Menyetujui Deployment

Bayangkan ini: seorang developer memperbaiki typo di halaman dokumentasi. Perubahannya hanya satu baris, tidak ada logika yang terpengaruh, tidak ada database yang disentuh. Namun proses deployment tetap membutuhkan dua persetujuan, waktu tunggu 30 menit di staging, dan tanda tangan dari engineering manager. Perbaikan yang seharusnya mencapai pengguna dalam lima malah memakan waktu setengah hari.

Sekarang bayangkan kebalikannya: seorang developer mengubah skrip migrasi database yang bisa mengunci tabel produksi. Pipeline yang sama memperlakukannya persis seperti perbaikan typo. Tidak ada review tambahan, tidak ada pemeriksaan ekstra. Perubahan itu lolos begitu saja, dan tim baru menyadari masalahnya ketika query mulai timeout.

Kedua skenario ini bermasalah, tetapi karena alasan yang berlawanan. Yang pertama memperlambat perubahan yang aman. Yang kedua membiarkan perubahan berbahaya lolos. Masalahnya adalah kebanyakan pipeline deployment menerapkan aturan yang sama untuk setiap perubahan, tanpa peduli apa yang sebenarnya berubah.

Mengapa Model Persetujuan Satu-Untuk-Semua Tidak Berfungsi

Kebanyakan tim memulai dengan model persetujuan sederhana: setiap deployment perlu review. Itu berhasil saat tim masih kecil dan setiap perubahan signifikan. Namun seiring pertumbuhan basis kode, model ini mulai rusak. Perubahan CSS dan refaktor modul pembayaran sama-sama membutuhkan tanda tangan yang sama. Developer mulai bermain-main dengan sistem, menggabungkan banyak perubahan sekaligus untuk mengurangi jumlah deployment, atau lebih parah lagi, melewatkan review sama sekali karena prosesnya terasa seperti birokrasi.

Masalah sebenarnya adalah risiko tidak seragam. Perubahan pada file README hampir tidak memiliki risiko operasional. Perubahan pada migrasi database atau modul autentikasi membawa risiko signifikan. Memperlakukan keduanya sama berarti Anda terlalu ketat untuk perubahan aman atau terlalu longgar untuk perubahan berisiko.

Bagaimana Pipeline Dapat Menilai Risiko Secara Otomatis

Alih-alih mengandalkan manusia untuk menilai setiap perubahan, Anda bisa mengajari pipeline untuk menilai risiko berdasarkan file apa saja yang dimodifikasi. Ini disebut risk scoring, dan cara kerjanya dengan mendefinisikan aturan yang memberikan poin pada perubahan berdasarkan cakupannya.

Satu set aturan sederhana mungkin terlihat seperti ini:

Berikut adalah bagaimana logika tersebut diterjemahkan ke dalam konfigurasi pipeline GitLab CI:

stages:
  - test
  - deploy

deploy:
  stage: deploy
  script:
    - echo "Deploying to production..."
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - "db/**/*"
        - "config/**/*"
      when: manual
      allow_failure: false
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - "docs/**/*"
        - "README.md"
      when: on_success
    - when: on_success
  • Perubahan pada file di docs/ atau README.md: 0 poin
  • Perubahan pada file konfigurasi (.env, config/): 3 poin
  • Perubahan pada logika bisnis di src/: 7 poin
  • Perubahan pada modul pembayaran atau autentikasi: 20 poin
  • Perubahan pada file migrasi database: 25 poin

Pipeline memindai pull request atau commit, memeriksa setiap file yang berubah terhadap aturan-aturan ini, dan menjumlahkan skor total. Skor tersebut kemudian menentukan apa yang terjadi selanjutnya.

Memetakan Skor Risiko ke Kebijakan Deployment

Setelah pipeline memiliki skor risiko, pipeline dapat menerapkan kebijakan yang berbeda berdasarkan hasilnya. Pengaturan tipikal mungkin memiliki tiga tingkatan:

Diagram alir berikut mengilustrasikan bagaimana pipeline memetakan skor risiko ke kebijakan deployment:

flowchart TD A[Perubahan Diajukan] --> B{Pindai File yang Berubah} B --> C[Tetapkan Skor Risiko] C --> D{Skor <= 5?} D -->|Ya| E[Risiko Rendah] E --> F[Setuju Otomatis] F --> G[Deploy ke Produksi] D -->|Tidak| H{Skor 6-15?} H -->|Ya| I[Risiko Sedang] I --> J[Perlukan Satu Persetujuan Rekan] J --> G H -->|Tidak| K[Risiko Tinggi] K --> L[Perlukan Dua Persetujuan] L --> M[Deploy ke Staging] M --> N[Jalankan Smoke Test & Monitor] N --> O{Pemeriksaan Lolos?} O -->|Ya| G O -->|Tidak| P[Blokir Deployment]

Risiko rendah (skor 0-5): Perubahan bisa langsung ke produksi tanpa persetujuan manual. Pipeline menjalankan tes otomatis, dan jika lolos, deployment berjalan. Ini mencakup perbaikan dokumentasi, perubahan konfigurasi minor, atau refaktor yang tidak menyentuh jalur kritis.

Risiko sedang (skor 6-15): Perubahan membutuhkan satu persetujuan dari rekan atau senior engineer. Pipeline berhenti setelah tes lolos dan menunggu tanda tangan manual sebelum melanjutkan ke produksi.

Risiko tinggi (skor 16+): Perubahan membutuhkan dua persetujuan dan harus menghabiskan setidaknya satu jam di staging dengan pemeriksaan monitoring yang lolos. Pipeline melakukan deploy ke staging terlebih dahulu, menjalankan smoke test, memeriksa tingkat error dan latensi, dan baru kemudian mengizinkan promosi final ke produksi.

Ambang batas ini tidak tetap. Lingkungan yang berbeda dapat memiliki aturan yang berbeda. Di lingkungan development, Anda mungkin memperlakukan semuanya sebagai risiko rendah karena tidak ada pengguna nyata. Di staging, Anda mungkin menaikkan ambang batas sedikit. Di produksi, Anda menerapkan aturan yang paling ketat.

Manfaat Sebenarnya Adalah Konsistensi, Bukan Akurasi Sempurna

Risk scoring tidak akan pernah sepenuhnya akurat. Perubahan satu baris di fungsi utilitas bisa merusak sesuatu yang tidak terduga jika fungsi itu dipanggil di banyak tempat. Refaktor besar yang menyentuh banyak file mungkin sebenarnya aman jika hanya mengganti nama variabel.

Tetapi akurasi sempurna bukanlah tujuannya. Tujuannya adalah mengganti penilaian manusia yang bersifat ad-hoc dengan proses yang konsisten dan transparan. Tanpa risk scoring, setiap deployment memulai perdebatan: "Apakah ini perlu persetujuan? Siapa yang harus mereview? Apakah ini cukup berisiko untuk memerlukan waktu staging?" Perdebatan itu membuang waktu dan menciptakan inkonsistensi. Satu minggu perubahan kecil dilewatkan begitu saja, minggu berikutnya jenis perubahan yang sama diblokir.

Dengan risk scoring, aturan dituliskan dan diterapkan secara otomatis. Tim bisa berdebat tentang aturan sekali, saat mereka menyusunnya, daripada berdebat tentang setiap deployment. Dan karena aturannya transparan, tim dapat meninjau dan menyesuaikannya seiring waktu saat mereka belajar jenis perubahan apa yang benar-benar menyebabkan masalah.

Bagaimana Ini Mengubah Perilaku Tim

Kontrol deployment berbasis risiko tidak hanya mengotomatiskan persetujuan. Ini mengubah cara developer berpikir tentang struktur kode. Ketika tim tahu bahwa perubahan apa pun di db/migrations/ secara otomatis memicu kebijakan risiko tinggi, mereka menjadi lebih berhati-hati tentang apa yang masuk ke folder itu. Mereka mungkin memisahkan perubahan skema database dari skrip migrasi data, sehingga data backfill sederhana tidak memicu pengawasan yang sama seperti perubahan skema.

Ini juga mendorong modularisasi yang lebih baik. Jika tim melihat bahwa perubahan pada modul tertentu selalu mendapat skor risiko tinggi, mereka mungkin melakukan refaktor modul itu untuk mengisolasi bagian yang benar-benar sensitif dari pembaruan rutin. Seiring waktu, basis kode menjadi lebih terstruktur secara sadar di sekitar batasan risiko.

Daftar Periksa Praktis untuk Menyiapkan Risk Scoring

Jika Anda ingin menerapkan pendekatan ini, berikut adalah daftar periksa awal:

  • Identifikasi folder dan pola file mana yang mewakili tingkat risiko berbeda di basis kode Anda
  • Definisikan sistem penilaian dengan nilai poin yang jelas untuk setiap pola
  • Tetapkan ambang batas untuk risiko rendah, sedang, dan tinggi di setiap lingkungan
  • Definisikan kebijakan deployment untuk setiap tingkat risiko (persetujuan yang diperlukan, waktu staging, pemeriksaan monitoring)
  • Implementasikan logika risk scoring di konfigurasi pipeline CI/CD Anda
  • Jalankan penilaian pada setiap pull request dan catat hasilnya untuk visibilitas
  • Tinjau aturan penilaian setelah satu bulan dan sesuaikan berdasarkan apa yang Anda pelajari

Pipeline Menjadi Pengambil Keputusan

Ketika Anda menambahkan kontrol deployment berbasis risiko, pipeline Anda tidak lagi hanya menjadi alat yang menjalankan perintah. Ia menjadi sistem pengambil keputusan yang mengevaluasi perubahan, menerapkan aturan, dan menentukan jalur yang tepat menuju produksi. Pipeline tidak sepenuhnya menggantikan penilaian manusia, tetapi ia menyediakan perhatian manusia hanya untuk perubahan yang benar-benar membutuhkannya.

Ini bukan tentang menghilangkan kontrol. Ini tentang menerapkan tingkat kontrol yang tepat untuk perubahan yang tepat. Perubahan kecil yang aman bergerak cepat. Perubahan besar yang berisiko mendapatkan pengawasan yang layak. Dan tim berhenti membuang energi untuk berdebat tentang hal-hal yang seharusnya sudah jelas.