Apa yang Terjadi Setelah Deployment: Promote, Hold, Rollback, Roll-Forward, Pause, atau Disable

Deployment baru saja selesai. Versi baru Anda sudah berjalan di produksi, melayani traffic nyata. Pipeline menunjukkan hijau, log mengalir, dan dashboard monitoring Anda mulai menampilkan data segar. Lalu, apa selanjutnya?

Momen antara deployment dan deklarasi sukses inilah yang sering membuat tim terjebak. Sebagian terburu-buru menyatakan selesai dan lanjut ke tugas lain. Sebagian lagi membeku, ragu apakah yang mereka lihat adalah fluktuasi normal atau awal dari bencana. Kenyataannya, deployment yang selesai bukanlah keputusan — melainkan awal dari sebuah keputusan.

Begitu sinyal observabilitas mulai masuk, Anda memiliki enam jalur ke depan. Masing-masing cocok untuk situasi berbeda, dan masing-masing membawa konsekuensi yang berbeda. Mengetahui kapan harus memilih yang mana, itulah yang membedakan tim yang menangani deployment dengan percaya diri dari tim yang hanya berharap semuanya baik-baik saja.

Promote: Versi Ini Bagus

Promote berarti Anda menyatakan versi baru sebagai versi produksi resmi. Semua traffic tetap mengarah ke versi ini, dan versi lama dapat diarsipkan atau dihapus. Ini adalah hasil yang diinginkan semua orang, tetapi jangan pernah terburu-buru hanya karena pipeline lolos.

Anda melakukan promote ketika semua sinyal observabilitas tetap dalam batas SLO Anda. Tingkat error normal, latensi tidak melonjak, error budget masih sehat, dan smoke test Anda lulus di produksi. Data mengonfirmasi apa yang disarankan pipeline: versi ini aman.

Jebakannya adalah melakukan promote terlalu cepat. Pipeline hijau berarti build dan pengujian lolos, tetapi itu tidak berarti perilaku di produksi sudah terverifikasi. Beri versi baru cukup waktu untuk mengumpulkan data yang bermakna sebelum menyatakannya selesai. Apa yang tampak stabil setelah dua menit bisa menunjukkan masalah setelah sepuluh menit.

Hold: Belum Yakin

Hold berarti versi baru tetap berjalan, tetapi Anda belum menyatakannya sebagai versi resmi. Anda menunggu lebih banyak data. Mungkin traffic masih meningkat, atau Anda melihat anomali kecil yang bisa berupa noise atau awal dari masalah yang lebih besar.

Hold adalah jalan tengah yang aman. Anda tidak panik, tetapi juga tidak merayakan. Versi terus melayani traffic sementara Anda mengamati pola. Konsekuensi utamanya adalah Anda tidak dapat memulai deployment berikutnya sampai yang ini terselesaikan. Hold memblokir pipeline, dan itu disengaja — memaksa tim untuk menyelidiki sebelum menumpuk perubahan di atas ketidakpastian.

Opsi ini cocok ketika Anda memiliki firasat ada yang salah tetapi belum ada bukti kuat. Percayalah pada firasat itu. Jika data tidak dengan jelas mengatakan "promote", jangan paksakan.

Rollback: Kembali ke yang Terbukti Berfungsi

Rollback berarti kembali ke versi stabil sebelumnya. Anda menarik versi baru dan mengembalikan versi lama untuk memegang kendali. Ini terasa seperti kegagalan, tetapi sebenarnya tidak. Ini adalah mundur secara terkendali dari situasi buruk.

Anda melakukan rollback ketika tingkat error melebihi SLO, error budget terbakar lebih cepat dari perkiraan, atau kegagalan kritis terdeteksi. Kriterianya jelas dan objektif. Jika angka menunjukkan versi baru lebih buruk dari versi lama, jangan ragu.

Tangkapannya adalah rollback hanya berfungsi jika Anda sudah mempersiapkannya. Mekanismenya harus diuji sebelum keadaan darurat, bukan dirancang saat darurat. Perubahan database yang tidak kompatibel ke belakang dapat membuat rollback tidak mungkin dilakukan, itulah mengapa roll-forward ada sebagai alternatif.

Roll-Forward: Perbaiki Maju, Bukan Mundur

Roll-forward berarti Anda mempertahankan versi saat ini tetap berjalan tetapi segera mulai membangun versi baru yang memperbaiki masalah. Alih-alih kembali, Anda mendorong perbaikan di atas rilis yang rusak.

Opsi ini masuk akal ketika masalahnya kecil dan tim Anda dapat menghasilkan perbaikan dengan cepat. Ini juga satu-satunya pilihan ketika rollback tidak memungkinkan — misalnya, ketika migrasi database mengubah skema dengan cara yang tidak dapat ditangani oleh kode lama.

Roll-forward membutuhkan keyakinan bahwa perbaikan benar-benar akan berhasil. Jika Anda hanya menebak, Anda bisa memperburuk keadaan. Ini juga memberi tekanan pada tim untuk mengirimkan dengan cepat, yang dapat mengarah pada keputusan tergesa-gesa. Gunakan roll-forward ketika jalannya jelas, bukan ketika Anda hanya berharap yang terbaik.

Pause: Berhenti dan Selidiki

Pause berarti Anda menghentikan proses deployment tanpa mengubah apa yang sedang berjalan. Versi baru tetap di tempatnya, tetapi tidak ada deployment lebih lanjut yang dapat dilanjutkan sampai penyelidikan selesai.

Gunakan pause ketika Anda melihat sesuatu yang aneh tetapi tidak cukup parah untuk memerlukan rollback. Latensi meningkat sedikit di satu region. Tingkat error naik sedikit tetapi masih dalam SLO. Satu endpoint menunjukkan perilaku tidak biasa sementara yang lainnya terlihat normal.

Pause memberi Anda waktu untuk memahami apa yang terjadi sebelum membuat keputusan yang lebih besar. Ini mencegah tim melakukan rollback terburu-buru yang mungkin tidak perlu, atau promote terburu-buru yang mungkin prematur. Biayanya adalah pipeline terblokir, tetapi itu harga kecil dibandingkan membuat keputusan yang salah.

Disable: Matikan Bagian yang Rusak

Disable berarti Anda menonaktifkan fitur atau fungsionalitas tertentu tanpa mengembalikan seluruh versi. Ini memerlukan feature flag atau mekanisme lain untuk mengaktifkan/menonaktifkan kemampuan individual secara independen.

Ini adalah intervensi paling ringan. Jika hanya satu fitur yang menyebabkan masalah — algoritma pencarian baru, alur checkout yang didesain ulang, endpoint API yang diubah — Anda dapat mematikan fitur itu sementara menjaga semuanya tetap berjalan. Pengguna kehilangan akses ke satu fitur itu, tetapi aplikasi lainnya berjalan normal.

Disable lebih cepat dan lebih aman daripada rollback ketika masalahnya terisolasi. Ini juga memberi tim waktu untuk memperbaiki fitur spesifik tanpa mengganggu seluruh deployment. Prasyaratnya adalah arsitektur Anda mendukung toggle granular, yang layak diinvestasikan jika Anda sering melakukan deployment.

Cara Memilih

Keputusan yang tepat tergantung pada tiga hal: seberapa buruk masalahnya, berapa banyak error budget yang tersisa, dan seberapa cepat tim Anda dapat merespons. Tim yang memiliki SLO yang ditentukan dan melacak error budget memiliki dasar objektif untuk keputusan ini. Jika error budget hampir habis, bahkan anomali kecil pun mungkin membenarkan rollback. Jika error budget berlimpah, Anda mungkin memilih hold atau pause untuk menyelidiki lebih lanjut.

Pohon keputusan berikut memetakan sinyal observabilitas Anda ke tindakan yang sesuai:

flowchart TD A[Deployment selesai, data monitoring tersedia?] -->|Ya| B{Semua sinyal dalam SLO?} A -->|Tidak| C[Tunggu data, lalu evaluasi ulang] B -->|Ya| D{Error budget hampir habis?} B -->|Tidak| E{Masalah terisolasi ke satu fitur?} D -->|Tidak| F[Promote] D -->|Ya| G{Hold atau Rollback?} G -->|Hold| H[Hold] G -->|Rollback| I[Rollback] E -->|Ya| J[Disable] E -->|Tidak| K{Bisa rollback dengan aman?} K -->|Ya| I K -->|Tidak| L{Perbaikan roll-forward siap?} L -->|Ya| M[Roll-Forward] L -->|Tidak| N[Pause]

Yang perlu dihindari adalah membuat keputusan ini hanya berdasarkan firasat. Ketika data jelas, jalannya jelas. Ketika data tidak jelas, tahan atau jeda sampai menjadi jelas.

Daftar Periksa Praktis untuk Keputusan Deployment

  • Apakah Anda sudah menunggu cukup lama agar data observabilitas yang bermakna terkumpul?
  • Apakah semua sinyal dalam batas SLO, atau ada anomali yang perlu diselidiki?
  • Apakah Anda memiliki mekanisme rollback yang sudah diuji, atau terhalang oleh perubahan database?
  • Apakah masalah terisolasi ke satu fitur yang dapat dinonaktifkan secara independen?
  • Apakah tim Anda memiliki kapasitas untuk membangun perbaikan dengan cepat jika Anda memilih roll-forward?
  • Apakah pipeline terblokir oleh hold atau pause, dan apakah semua orang tahu alasannya?

Intisari

Deployment tidak selesai ketika kode sudah berjalan. Deployment selesai ketika Anda memiliki cukup data untuk membuat keputusan yang percaya diri tentang apa yang harus dilakukan selanjutnya. Keenam opsi — promote, hold, rollback, roll-forward, pause, dan disable — memberi Anda kosakata untuk keputusan itu. Gunakan dengan sengaja, berdasarkan sinyal, bukan tebakan. Versi yang Anda deploy bukanlah jawaban akhir. Keputusan yang Anda buat setelah melihatnya berjalan itulah jawabannya.