Kapan Pipeline Anda Harus Menunggu Manusia?

Bayangkan ini: pipeline CI/CD Anda baru saja selesai membangun dan menguji fitur baru. Semua pemeriksaan lolos. Pemindaian keamanan tidak menemukan sesuatu yang mencurigakan. Lingkungan staging menjalankan versi baru tanpa masalah. Sekarang pipeline ingin mendorong versi yang sama ke produksi. Haruskah pipeline langsung melanjutkan, atau berhenti dan menunggu seseorang berkata "ya"?

Pertanyaan ini muncul di setiap tim yang membangun pipeline deployment dengan banyak lingkungan. Jawabannya bukan sekadar ya atau tidak. Ini tergantung pada seberapa besar Anda percaya pada setiap lingkungan, dan seberapa besar risiko yang bersedia Anda terima.

Argumen untuk Membiarkan Pipeline Berjalan

Di lingkungan awal seperti development, sebagian besar tim membiarkan pipeline mempromosikan perubahan secara otomatis. Build berhasil, pengujian lolos, pemindaian keamanan bersih -- dan pipeline segera men-deploy versi tersebut ke lingkungan berikutnya. Tidak ada yang perlu mengklik tombol. Ini disebut automatic promotion.

Automatic promotion itu cepat. Pengembang tidak perlu menunggu seseorang menyetujui deployment ke staging setiap kali mereka mendorong perbaikan kecil. Pipeline dapat memproses puluhan perubahan per hari tanpa tim menjadi hambatan. Untuk lingkungan tahap awal di mana kesalahan tidak terlalu berdampak, kecepatan ini sangat berharga.

Namun automatic promotion tidak tepat untuk setiap situasi. Semakin dekat perubahan ke produksi, semakin besar dampaknya jika terjadi kesalahan. Pada titik tertentu, tim mungkin ingin berhenti sejenak, melihat hasil pengujian dari staging, lalu memutuskan apakah perubahan harus dilanjutkan.

Kapan Anda Membutuhkan Manusia dalam Proses

Manual promotion berarti pipeline berhenti di batas lingkungan tertentu dan menunggu seseorang memberikan izin untuk melanjutkan. Ini biasanya terjadi sebelum produksi, atau sebelum lingkungan yang diakses oleh pengguna nyata. Pipeline sudah melakukan semua persiapan -- versi baru sudah dibangun, diuji di staging, dan diperiksa keamanannya -- tetapi tidak akan masuk ke produksi sampai seseorang menyetujuinya.

Tim biasanya memutuskan untuk menggunakan manual promotion berdasarkan dua faktor: seberapa kritis lingkungan target, dan seberapa besar perubahannya.

Untuk lingkungan produksi, banyak tim menggunakan manual promotion sebagai jaring pengaman terakhir. Semua gate otomatis sudah lolos. Staging berjalan normal. Namun tim masih ingin seseorang secara sadar memeriksa sebelum perubahan mencapai pengguna. Orang yang memberikan persetujuan biasanya adalah senior engineer, tech lead, atau seseorang yang memahami dampak penuh perubahan pada sistem.

Untuk perubahan besar -- migrasi basis data, perubahan arsitektur, atau pembaruan library utama -- manual promotion sering digunakan bahkan untuk lingkungan staging. Tim ingin memastikan seseorang memperhatikan sebelum perubahan berpindah ke tahap berikutnya.

Pola Umum: Otomatis di Awal, Manual di Akhir

Pendekatan yang paling umum adalah kombinasi: automatic promotion untuk lingkungan awal, manual promotion untuk lingkungan terakhir. Pipeline mempromosikan dirinya sendiri dari development ke staging, lalu berhenti di gerbang produksi menunggu persetujuan. Atau pipeline mempromosikan secara otomatis ke staging, tim QA memeriksa secara manual, lalu memberikan persetujuan untuk masuk ke produksi.

Diagram alir berikut mengilustrasikan pola umum ini dengan titik keputusan untuk perubahan berisiko tinggi:

flowchart TD Dev[Development] -->|auto-promote| Staging[Staging] Staging -->|auto-promote| PreProd[Pre-Production] PreProd --> IsHighRisk{Apakah ini perubahan berisiko tinggi?} IsHighRisk -->|Tidak| AutoProd[Auto-promote ke Production] IsHighRisk -->|Ya| ManualGate[Gerbang Persetujuan Manual] ManualGate -->|disetujui| Prod[Production] ManualGate -->|ditolak| Stop[Berhenti / Rollback]

Beberapa tim menerapkan manual promotion berlapis. Misalnya, pindah ke staging memerlukan persetujuan dari senior developer, sementara pindah ke produksi memerlukan persetujuan dari tech lead dan tim QA. Semakin tinggi lingkungan, semakin banyak orang yang perlu setuju.

Apa yang Bukan Manual Promotion

Manual promotion bukan pengganti gate otomatis. Gate otomatis tetap berjalan di setiap lingkungan. Pipeline tetap memeriksa build, pengujian, dan keamanan sebelum berhenti menunggu persetujuan. Manual promotion menambahkan lapisan keputusan manusia di atas pemeriksaan otomatis. Ini tidak menggantikannya.

Jika pipeline Anda melewatkan pemeriksaan otomatis dan hanya mengandalkan persetujuan manual, Anda tidak melakukan manual promotion. Anda melakukan deployment manual dengan langkah tambahan. Nilai dari manual promotion berasal dari memiliki keduanya: verifikasi otomatis yang ketat ditambah penilaian manusia yang terinformasi.

Daftar Periksa Praktis untuk Memutuskan

Saat Anda menyiapkan aturan promosi untuk pipeline, ajukan pertanyaan-pertanyaan ini:

  • Apakah lingkungan ini digunakan oleh pengguna nyata? Jika ya, pertimbangkan manual promotion.
  • Bisakah kesalahan di sini memengaruhi integritas data atau menyebabkan downtime? Jika ya, manual promotion lebih aman.
  • Apakah tim memiliki kepercayaan yang cukup pada pengujian otomatis untuk lingkungan ini? Jika tidak, tambahkan review manual.
  • Apakah ini perubahan rutin (pembaruan konfigurasi, fitur minor) atau perubahan berisiko tinggi (migrasi skema, upgrade library)? Perubahan berisiko tinggi mendapat manfaat dari persetujuan manual bahkan di staging.
  • Berapa lama persetujuan manual biasanya memakan waktu? Jika memakan waktu berjam-jam, tim mungkin enggan melakukan deploy secara sering. Seimbangkan keamanan dengan kecepatan.

Kesimpulan

Manual promotion adalah jeda yang disengaja, bukan gatekeeper yang memperlambat segalanya. Gunakan di mana biaya kesalahan lebih tinggi daripada biaya menunggu manusia untuk meninjau. Untuk lingkungan awal, biarkan pipeline berjalan. Untuk produksi dan perubahan berisiko tinggi, biarkan manusia yang memutuskan. Pipeline terbaik menggabungkan ketelitian otomatis dengan penilaian manusia pada momen yang tepat.