Buat keputusan rilis berdasarkan bukti

Nyatakan keputusan secara tepat

Pipeline hijau merupakan bukti dari serangkaian pemeriksaan. Pipeline tersebut bukan penjelasan lengkap tentang keputusan rilis. Penanggung jawab perlu mengetahui apa yang akan berubah, di mana perubahan terjadi, dan dampak yang tersisa.

Untuk ekspor pelanggan fiktif, identifikasi commit yang diterima dan artefak yang dihasilkan darinya. Sebutkan lingkungan target. Tautkan pengujian, peninjauan, dan pengecualian yang disetujui jika ada. Sertakan perubahan data atau infrastruktur yang menyertai aplikasi.

SSDF NIST menyediakan praktik pengembangan aman, sedangkan provenance SLSA membantu menjelaskan cara artefak dihasilkan. Keduanya tidak menghilangkan kebutuhan untuk memutuskan apakah rilis ini sesuai untuk layanan ini. NIST SSDF, provenance SLSA.

Pisahkan tiga peristiwa

Merge memasukkan perubahan kode sumber ke branch. Deployment menempatkan artefak ke lingkungan. Pembukaan akses fitur membuat perilaku tersedia bagi pengguna. Peristiwa ini dapat terjadi bersamaan, tetapi tidak selalu merupakan peristiwa yang sama.

Layanan dapat melakukan deployment fitur yang belum aktif dan membukanya nanti. Migrasi database dapat memengaruhi produksi sebelum fitur terlihat. Tentukan urutan yang sebenarnya alih-alih berasumsi bahwa merge PR menjelaskan setiap dampak.

Untuk ekspor, feature flag dapat membatasi akses awal. Feature flag tidak otomatis melindungi endpoint baru atau membatalkan migrasi skema. Verifikasi kontrol di titik terjadinya dampak.

Tinjau catatan bukti yang ringkas

Gunakan catatan yang dapat diperiksa penanggung jawab lain:

• Tujuan dan pengguna yang terdampak.
• Identitas commit dan artefak.
• Pemeriksaan perilaku, keamanan, dan kompatibilitas yang relevan.
• Lingkungan target dan identitas eksekusi.
• Pengecualian tersisa beserta penanggung jawab dan kondisi berakhirnya.
• Pemantauan, metode pemulihan, dan penanggung jawab respons.

Buat klaim yang spesifik. “Pengujian lulus” lebih lemah daripada tautan hasil untuk commit rilis dengan penjelasan cakupan yang jelas. “Rollback tersedia” lebih lemah daripada prosedur yang telah diuji dengan batas yang dinyatakan.

Tentukan cara menghentikan rilis

Tetapkan syarat rilis sebelum eksekusi. Untuk ekspor fiktif, hentikan jika akses lintas organisasi berhasil, artefak berbeda dari digest yang diterima, atau pemulihan tidak tersedia. Ini contoh syarat, bukan daftar pemeriksaan universal.

Setelah deployment, periksa sinyal yang penting bagi pengguna. Bandingkan perilaku error dan waktu respons dengan target layanan yang diterima. Proses yang sehat tidak membuktikan bahwa alur kerja pengguna berfungsi.

Jika suatu syarat tidak terpenuhi, gunakan respons yang disepakati. Respons dapat berupa menutup akses fitur, melakukan rollback kode yang kompatibel, atau memulihkan data. Pilih tindakan yang menangani kegagalan tanpa menimbulkan kegagalan lebih besar.

Pertahankan catatan keputusan setelah rilis

Catat artefak yang benar-benar di-deploy dan hasilnya. Jika eksekusi berbeda dari rencana, tampilkan perbedaannya. Gunakan insiden dan pekerjaan yang tidak diperkirakan untuk merancang rilis berikutnya.

Sistem pengiriman otomatis seharusnya membuat catatan ini lebih mudah diperiksa. Peninjau tidak seharusnya perlu menyusun ulang rilis dari percakapan, log, dan tangkapan layar yang terpisah-pisah. Bukti yang jelas memungkinkan tim mengotomatiskan pekerjaan rutin sambil menjaga keputusan yang dapat dipertanggungjawabkan.