Blue-Green Deployment dengan Health Check dan Rollback Cepat adalah pola rilis yang menurunkan risiko perubahan produksi dengan menyiapkan dua environment identik: satu melayani trafik aktif, satu lagi menerima versi baru. Setelah versi baru lulus health check dan verifikasi dasar, trafik dialihkan ke environment baru. Jika metrik memburuk, rollback dilakukan dengan mengalihkan trafik kembali ke environment lama.

Untuk aplikasi web dan backend, pendekatan ini efektif ketika target utama Anda adalah minim downtime, validasi rilis yang terukur, dan pemulihan cepat tanpa menunggu proses build ulang. Kunci keberhasilannya bukan hanya pada mekanisme switch trafik, tetapi pada urutan deployment yang disiplin: health check yang benar, observability yang memadai, migrasi database yang kompatibel, dan runbook rollback yang benar-benar bisa dijalankan di bawah tekanan.

Apa itu blue-green deployment dan kapan cocok digunakan

Dalam pola ini, ada dua stack aplikasi yang setara:

  • Blue: environment yang saat ini menerima trafik produksi.
  • Green: environment kandidat rilis berikutnya.

Deploy dilakukan ke green terlebih dahulu. Setelah aplikasi siap dan lolos pemeriksaan, load balancer atau reverse proxy mengalihkan trafik dari blue ke green. Karena environment lama masih utuh, rollback bisa sangat cepat: cukup arahkan trafik kembali ke blue.

Kapan pendekatan ini tepat

  • Aplikasi harus mengurangi downtime saat rilis.
  • Rollback harus cepat dan sederhana.
  • Anda memiliki kontrol atas routing trafik.
  • Infrastruktur mampu menjalankan dua environment paralel untuk sementara.

Kapan kurang cocok

  • Sumber daya komputasi sangat terbatas, sehingga menjalankan dua stack paralel terlalu mahal.
  • Perubahan database tidak kompatibel mundur, sehingga versi lama tidak bisa bekerja setelah migrasi.
  • Aplikasi sangat bergantung pada state lokal di instance, bukan state yang dipindahkan ke storage bersama atau komponen eksternal.

Prasyarat sebelum menerapkan blue-green deployment

1. Build artefak yang konsisten

Versi yang dirilis harus berasal dari artefak yang dapat diulang, misalnya image container atau paket build yang sama antara staging dan production. Hindari membangun ulang dari source yang mungkin berubah di tengah proses rilis.

2. Konfigurasi environment yang dapat diprediksi

Blue dan green harus sedekat mungkin: variabel environment, dependency eksternal, konfigurasi jaringan, dan secret management harus konsisten. Banyak insiden rilis bukan karena kode, tetapi karena perbedaan konfigurasi antar environment.

3. Health check yang bermakna

Health check tidak boleh sekadar mengembalikan HTTP 200 tanpa memeriksa kemampuan dasar aplikasi. Minimal, pisahkan dua jenis endpoint:

  • Liveness check: proses masih hidup.
  • Readiness check: aplikasi siap menerima trafik, termasuk koneksi ke dependency penting jika memang wajib untuk melayani request.

Jika readiness terlalu dangkal, trafik bisa dialihkan ke instance yang sebenarnya belum siap. Jika terlalu ketat, instance sehat bisa dianggap gagal karena dependency non-kritis sedang lambat. Desain endpoint ini harus sesuai kebutuhan layanan Anda.

4. Observability minimum yang wajib ada

Sebelum berbicara soal rollback cepat, pastikan Anda bisa melihat gejala masalah dalam hitungan menit. Minimal siapkan:

  • Error rate HTTP atau RPC.
  • Latency, idealnya per persentil seperti p95 atau p99.
  • Request throughput.
  • Status code 5xx dan lonjakan 4xx yang tidak normal.
  • Resource usage: CPU, memory, restart process/container.
  • Database error, connection saturation, atau timeout ke dependency.
  • Log terstruktur dengan korelasi request atau trace ID bila tersedia.

5. Migrasi database yang kompatibel

Ini titik yang paling sering merusak rollback. Saat blue dan green hidup bersamaan, dua versi aplikasi mungkin mengakses schema yang sama. Karena itu, gunakan prinsip expand-and-contract:

  1. Expand: tambahkan kolom, tabel, indeks, atau struktur baru tanpa memutus kompatibilitas versi lama.
  2. Deploy aplikasi baru yang bisa membaca/menulis skema lama dan baru bila perlu.
  3. Lakukan backfill data jika dibutuhkan.
  4. Setelah versi lama tidak dipakai lagi, lakukan contract: hapus kolom lama atau constraint lama di rilis terpisah.

Hindari perubahan yang membuat versi lama langsung rusak, misalnya mengganti nama kolom yang masih dibaca aplikasi lama atau menghapus field yang masih dipakai saat rollback.

6. Session dan state tidak melekat ke instance

Jika aplikasi web menyimpan session di memori lokal instance, cutover dapat menyebabkan logout massal atau perilaku tidak konsisten. Simpan session dan state penting di komponen bersama yang dapat diakses kedua environment, atau gunakan pendekatan stateless bila memungkinkan.

Alur deployment blue-green yang praktis

Arsitektur singkat

Secara umum alurnya seperti ini:

  1. Blue aktif menerima trafik produksi.
  2. Deploy versi baru ke green.
  3. Jalankan health check dan verifikasi fungsional minimum di green tanpa trafik publik penuh.
  4. Alihkan trafik ke green.
  5. Pantau metrik kritis selama jendela observasi.
  6. Jika sehat, tetapkan green sebagai aktif dan siapkan blue sebagai kandidat berikutnya.
  7. Jika memburuk, rollback dengan mengalihkan trafik ke blue.

Urutan deployment yang disarankan

  1. Bekukan perubahan non-esensial saat rilis

    Kurangi variabel yang berubah bersamaan. Jangan gabungkan deploy aplikasi, perubahan infrastruktur besar, dan migration berisiko tinggi dalam satu jendela jika tidak perlu.

  2. Deploy artefak ke green

    Pastikan semua instance green sudah menjalankan versi yang sama.

  3. Jalankan migration yang aman

    Utamakan migration yang backward-compatible. Jika migration berat, pertimbangkan menjalankannya sebelum cutover dan ukur dampaknya ke database.

  4. Warm-up aplikasi

    Biarkan cache, koneksi pool, dan dependency initialization selesai. Aplikasi yang baru start sering menunjukkan lonjakan latency sesaat jika langsung menerima trafik penuh.

  5. Readiness check dan smoke test

    Uji endpoint utama, koneksi database, autentikasi, dan integrasi penting. Ini tidak menggantikan test suite, tetapi berfungsi sebagai pagar terakhir sebelum trafik publik diarahkan.

  6. Cutover trafik

    Alihkan trafik dari blue ke green melalui komponen routing yang Anda miliki, misalnya load balancer atau reverse proxy. Pastikan strategi drain untuk koneksi lama telah dipikirkan, terutama jika ada long-lived connection.

  7. Verifikasi pasca-cutover

    Pantau metrik dalam jangka pendek. Banyak masalah baru muncul hanya setelah trafik nyata masuk: query berat, memory leak, lock contention, atau timeout dependency.

  8. Rollback bila ambang terlampaui

    Jika error rate naik signifikan atau latency memburuk di luar ambang yang ditetapkan, rollback lebih aman daripada menebak-nebak perbaikan di produksi.

Contoh health check yang lebih berguna

Contoh berikut bukan standar baku, tetapi menggambarkan pemisahan endpoint dasar:

GET /health/live
200 OK
{ "status": "live" }

GET /health/ready
200 OK
{
  "status": "ready",
  "checks": {
    "database": "ok",
    "queue": "ok"
  }
}

Gunakan readiness untuk memastikan layanan inti tersedia. Namun hati-hati: jika queue bukan dependency wajib untuk melayani semua request, Anda tidak harus menggagalkan seluruh readiness hanya karena queue worker tertunda. Bedakan dependency kritis dan non-kritis.

Checklist verifikasi sebelum dan sesudah cutover

Checklist sebelum cutover

  • Artefak yang benar sudah terpasang di green.
  • Konfigurasi environment green sesuai dengan production.
  • Readiness check lulus pada seluruh instance green.
  • Migration database sudah dijalankan dan kompatibel mundur.
  • Smoke test endpoint utama lulus.
  • Dashboard observability untuk error rate, latency, throughput, dan resource usage sudah siap dipantau.
  • Runbook rollback tersedia dan dipahami on-call engineer.
  • Perubahan melalui feature flag yang sensitif masih dalam posisi aman atau dinonaktifkan.

Checklist sesudah cutover

  • Error rate tidak meningkat di atas ambang normal.
  • Latency p95/p99 tidak naik signifikan dibanding baseline.
  • Tidak ada lonjakan 5xx, timeout, atau retry storm ke dependency.
  • Throughput sesuai ekspektasi dan tidak turun tanpa sebab jelas.
  • CPU dan memory stabil, tidak ada restart berulang.
  • Log tidak menunjukkan exception baru yang masif.
  • Fungsi bisnis utama berhasil diuji pada trafik nyata, misalnya login, create/update data, dan callback eksternal.

Catatan: Jangan hanya melihat status HTTP 200. Banyak rilis terlihat “up” tetapi sebenarnya rusak secara fungsional, misalnya antrean menumpuk, transaksi gagal commit, atau respons lambat karena query baru tidak menggunakan indeks dengan baik.

Indikator observability yang wajib dipantau

1. Error rate

Ini indikator rollback paling jelas. Fokus pada:

  • Persentase 5xx.
  • Error aplikasi yang tertangkap di log.
  • Kegagalan koneksi ke database, cache, atau API eksternal.

Bandingkan terhadap baseline normal, bukan angka absolut tanpa konteks. Kenaikan kecil pada layanan sensitif bisa lebih penting daripada nilai besar pada endpoint non-kritis.

2. Latency

Gunakan persentil, bukan rata-rata semata. Rata-rata sering menutupi ekor distribusi yang memburuk. Perhatikan:

  • Latency endpoint bisnis utama.
  • Waktu query database.
  • Durasi panggilan ke dependency eksternal.

3. Saturasi resource

Lonjakan CPU, memory, thread, file descriptor, atau connection pool sering muncul beberapa menit setelah cutover. Jika aplikasi tampak sehat tetapi resource mendekati batas, rollback atau mitigasi segera bisa lebih bijak daripada menunggu crash.

4. Sinyal bisnis minimum

Untuk layanan yang berdampak langsung pada pengguna, pantau metrik bisnis dasar bila tersedia, misalnya transaksi sukses, login berhasil, atau order yang selesai. Metrik teknis bisa tampak normal sementara fungsi bisnis utama sebenarnya gagal.

5. Perbedaan antara blue dan green

Jika memungkinkan, labeli metrik per environment. Ini memudahkan pembandingan langsung antara perilaku blue dan green selama jendela observasi. Tanpa pemisahan ini, diagnosis akan lebih lambat.

Rollback cepat: kapan dilakukan dan bagaimana melakukannya

Kapan rollback lebih tepat daripada hotfix

Rollback umumnya pilihan yang lebih aman jika:

  • Error rate naik segera setelah cutover.
  • Latency meningkat cukup besar dan memengaruhi endpoint utama.
  • Ada indikasi bug regresi yang belum dipahami akar masalahnya.
  • Masalah menyentuh jalur kritis seperti autentikasi, pembayaran, atau penyimpanan data.
  • Perbaikan cepat belum pasti atau memerlukan perubahan kode yang tidak sempat divalidasi.

Hotfix di atas environment yang sedang bermasalah layak dipilih hanya jika masalahnya sangat terlokalisasi, mitigasinya jelas, dan risikonya lebih rendah daripada rollback. Dalam banyak kasus produksi, rollback lebih cepat, lebih sederhana, dan lebih bisa diprediksi.

Prinsip rollback yang sehat

  • Rollback trafik, bukan rebuild. Kembalikan routing ke blue yang masih utuh.
  • Jangan mengubah terlalu banyak hal saat insiden. Fokus pada pemulihan layanan lebih dulu.
  • Pastikan kompatibilitas database. Jika migration tidak backward-compatible, rollback aplikasi saja bisa gagal.
  • Catat waktu cutover dan rollback. Ini penting untuk analisis insiden dan korelasi metrik.

Contoh runbook rollback

  1. Konfirmasi sinyal rollback: error rate, latency, atau kegagalan bisnis melewati ambang.
  2. Umumkan status di kanal insiden internal agar semua pihak memiliki konteks yang sama.
  3. Alihkan trafik dari green kembali ke blue.
  4. Verifikasi metrik blue pulih ke baseline.
  5. Jika perlu, nonaktifkan feature flag yang baru diaktifkan.
  6. Bekukan deploy lanjutan sampai akar masalah dipahami.
  7. Kumpulkan log, metrik, dan timeline insiden.

Runbook harus singkat, jelas, dan bisa dijalankan oleh engineer yang sedang on-call tanpa harus menebak langkah berikutnya.

Tindakan pencegahan agar rilis lebih aman

Feature flag untuk memisahkan deploy dari release

Feature flag memungkinkan kode baru sudah ter-deploy tanpa langsung mengaktifkan perilaku baru untuk semua pengguna. Ini berguna untuk:

  • Mengurangi blast radius.
  • Mematikan fitur baru tanpa redeploy penuh.
  • Menguji fitur secara bertahap pada subset trafik atau pengguna internal.

Namun feature flag juga menambah kompleksitas. Pastikan ada kepemilikan yang jelas, masa berlaku, dan pembersihan flag yang sudah tidak dipakai.

Migration database yang aman

Beberapa praktik yang umum membantu:

  • Tambahkan kolom baru sebelum aplikasi mulai membacanya.
  • Hindari rename atau drop kolom dalam rilis yang sama dengan cutover.
  • Backfill data secara bertahap bila volumenya besar.
  • Uji migration pada data yang representatif, bukan hanya database kecil.
  • Perhatikan lock dan dampak performa saat membuat indeks atau mengubah constraint.

Batasi perubahan per rilis

Rilis yang kecil lebih mudah diverifikasi dan lebih mudah di-rollback. Jika memungkinkan, pisahkan perubahan berisiko tinggi, terutama yang menyentuh query berat, autentikasi, pipeline async, atau dependency eksternal baru.

Siapkan fallback untuk dependency eksternal

Jika versi baru menambah panggilan ke service lain, pikirkan timeout yang masuk akal, circuit breaker, atau degradsi fungsional. Banyak rollback dipicu bukan oleh bug lokal, tetapi karena kode baru memperburuk kegagalan dependency yang sebenarnya sudah rapuh.

Contoh alur rilis yang bisa diadopsi tim kecil

  1. Merge perubahan kecil dan jalankan test otomatis.
  2. Buat artefak rilis yang immutable.
  3. Deploy ke green.
  4. Jalankan migration backward-compatible.
  5. Warm-up instance dan jalankan readiness check.
  6. Lakukan smoke test: login, baca data, tulis data, dan satu alur bisnis utama.
  7. Cutover trafik ke green.
  8. Pantau 10-30 menit pertama dengan fokus pada error rate, latency p95, dan metrik bisnis minimum.
  9. Jika ada anomali yang jelas, rollback segera.
  10. Jika stabil, tutup jendela rilis dan dokumentasikan hasilnya.

Durasi observasi bergantung pada pola trafik aplikasi Anda. Layanan dengan trafik rendah mungkin membutuhkan waktu lebih lama untuk menyimpulkan bahwa tidak ada regresi.

Kesalahan umum saat menerapkan blue-green deployment

  • Menganggap health check sama dengan pengujian fungsional.
    Aplikasi bisa “ready” tetapi fitur utama rusak.
  • Tidak memisahkan metrik per environment.
    Akibatnya sulit menentukan apakah green memang penyebab degradasi.
  • Migration database tidak backward-compatible.
    Ini membuat rollback praktis tidak aman.
  • Session menempel pada instance lama.
    Cutover memicu logout atau request gagal.
  • Tidak punya ambang rollback yang jelas.
    Tim akhirnya terlalu lama berdebat saat insiden berlangsung.
  • Runbook rollback tidak pernah diuji.
    Dokumen ada, tetapi tidak realistis ketika dipakai dalam kondisi darurat.

Debugging cepat saat cutover bermasalah

Jika error rate naik

  • Periksa log exception yang baru muncul hanya di green.
  • Bandingkan konfigurasi blue dan green.
  • Pastikan secret, endpoint dependency, dan permission tidak berbeda.
  • Lihat apakah ada migration yang mengubah perilaku query atau validasi data.

Jika latency naik

  • Periksa query database yang melambat.
  • Lihat saturasi connection pool dan timeout ke dependency eksternal.
  • Periksa apakah cache belum hangat atau terjadi stampede.
  • Bandingkan profil resource antara blue dan green.

Jika hanya fitur tertentu yang rusak

  • Gunakan feature flag untuk mematikan bagian yang baru bila memungkinkan.
  • Tentukan apakah rollback penuh lebih aman daripada mitigasi parsial.
  • Pastikan tidak ada data yang sudah ditulis dalam format baru yang tidak dipahami versi lama.

Postmortem ringan setelah insiden rilis

Jika rollback terjadi, jangan berhenti di pemulihan layanan. Lakukan postmortem ringan agar masalah tidak berulang. Tidak harus panjang, tetapi harus spesifik.

Format sederhana yang efektif

  • Ringkasan insiden: apa yang berubah dan apa dampaknya.
  • Timeline: kapan deploy, cutover, deteksi masalah, rollback, dan pemulihan.
  • Gejala utama: error rate naik, latency meningkat, transaksi gagal, dan sebagainya.
  • Akar masalah: bug regresi, migration, konfigurasi, dependency, atau observability yang kurang.
  • Yang berjalan baik: misalnya rollback cepat berhasil karena runbook jelas.
  • Yang perlu diperbaiki: smoke test kurang, threshold alert terlalu lambat, dashboard tidak memisahkan green.
  • Tindak lanjut: action item yang punya owner dan tenggat.

Tujuan postmortem bukan mencari kambing hitam, tetapi memperbaiki sistem, proses rilis, dan alat bantu observability.

Penutup

Blue-Green Deployment dengan Health Check dan Rollback Cepat bekerja baik ketika diperlakukan sebagai proses operasional yang lengkap, bukan sekadar teknik mengalihkan trafik. Health check memastikan kandidat rilis benar-benar siap, observability memberi sinyal objektif setelah cutover, dan rollback yang sederhana menjaga waktu pemulihan tetap pendek.

Jika Anda baru menerapkannya, mulai dari versi yang sederhana: dua environment yang konsisten, readiness check yang benar, migration database yang kompatibel mundur, dashboard metrik minimum, dan runbook rollback yang diuji. Dari sana, barulah tambahkan lapisan pengaman seperti feature flag, smoke test yang lebih kaya, dan otomatisasi cutover yang lebih matang.