Blue-green deployment Spring Boot adalah strategi rilis dengan menyiapkan dua lingkungan identik: blue (versi aktif saat ini) dan green (versi baru). Trafik dialihkan ke lingkungan baru hanya setelah aplikasi lolos health check, verifikasi readiness, dan pengamatan sinyal error. Jika setelah cutover error rate naik, rollback bisa dilakukan cepat dengan mengarahkan trafik kembali ke lingkungan lama tanpa perlu build ulang.

Untuk tim backend Java, pendekatan ini cocok ketika target utamanya adalah minim downtime, rollback yang terprediksi, dan kontrol lebih baik terhadap risiko rilis. Kunci keberhasilannya bukan hanya di proses switch trafik, tetapi juga pada kesiapan aplikasi Spring Boot, kompatibilitas skema database, serta observabilitas yang cukup untuk mendeteksi masalah dalam menit pertama setelah rilis.

Konsep dasar blue-green deployment

Pada strategi ini, dua stack aplikasi berjalan paralel:

  • Blue: versi produksi yang saat ini menerima trafik.
  • Green: versi baru yang sudah dideploy, diuji, tetapi belum menerima seluruh trafik.

Setelah green dinyatakan sehat, load balancer atau gateway mengalihkan trafik dari blue ke green. Bila ditemukan masalah, trafik dikembalikan lagi ke blue. Karena lingkungan lama tetap hidup, rollback jauh lebih cepat dibanding strategi yang mengganti instance secara langsung.

Kapan strategi ini layak dipilih

  • Aplikasi harus tetap tersedia selama rilis.
  • Rollback perlu dilakukan dalam hitungan menit.
  • Tim memiliki kontrol terhadap routing trafik di load balancer, gateway, atau ingress.
  • Perubahan database bisa dibuat kompatibel untuk dua versi aplikasi selama masa transisi.

Trade-off yang perlu dipahami

  • Biaya infrastruktur lebih tinggi karena dua lingkungan aktif bersamaan.
  • Database menjadi titik kritis; rollback aplikasi tidak selalu berarti rollback data aman dilakukan.
  • Stateful session perlu perhatian khusus jika sesi tersimpan lokal di instance.
  • Observabilitas harus memadai; tanpa metrik dan alert, rollback akan terlambat.

Arsitektur umum untuk Spring Boot

Berikut arsitektur generik yang umum dipakai untuk implementasi blue-green deployment pada Spring Boot:

Client
  |
  v
Load Balancer / API Gateway / Ingress
  |----------------------|
  v                      v
Blue Environment      Green Environment
(Spring Boot v1)      (Spring Boot v2)
  |                      |
  |---- shared dependencies ----|
             Database
             Cache/Message Broker
             Log & Metrics Backend

Ada dua pola umum untuk dependency:

  • Shared dependency: blue dan green memakai database yang sama. Ini paling umum, tetapi menuntut migrasi skema yang kompatibel.
  • Isolated dependency: blue dan green punya database terpisah lalu sinkronisasi data dilakukan secara khusus. Ini lebih kompleks dan tidak selalu diperlukan.

Untuk mayoritas layanan Spring Boot berbasis API, pola shared database lebih realistis, asalkan tim menerapkan prinsip expand and contract migration dan menghindari perubahan skema yang memutus kompatibilitas antar versi.

Menyiapkan Spring Boot: actuator, health check, readiness, dan liveness

Pada blue-green deployment, keputusan menerima trafik seharusnya tidak didasarkan pada fakta bahwa proses Java berhasil start saja. Aplikasi harus benar-benar siap menerima request: koneksi database stabil, dependency penting tersedia, dan startup tasks selesai.

Actuator untuk health endpoint

Spring Boot Actuator umum dipakai untuk menyediakan endpoint health. Endpoint ini kemudian dibaca oleh orchestrator, load balancer, atau script verifikasi.

management.endpoints.web.exposure.include=health,info,metrics,prometheus
management.endpoint.health.probes.enabled=true
management.health.livenessstate.enabled=true
management.health.readinessstate.enabled=true

Konfigurasi di atas adalah contoh umum yang menunjukkan niat implementasi: mengekspose health endpoint dan mengaktifkan liveness serta readiness. Detail properti bisa sedikit berbeda tergantung setup, jadi verifikasi dengan dokumentasi Spring Boot yang digunakan tim Anda.

Perbedaan readiness dan liveness

  • Liveness: menandakan proses aplikasi masih hidup. Jika gagal, biasanya perlu restart.
  • Readiness: menandakan aplikasi siap menerima trafik. Jika gagal, instance jangan diberi request baru dulu.

Kesalahan umum adalah menggabungkan semuanya ke satu health check berat. Akibatnya, restart terjadi terlalu agresif atau instance sehat dianggap gagal hanya karena dependency non-kritis lambat.

Praktik yang disarankan untuk health indicator

  • Masukkan database sebagai bagian dari readiness jika aplikasi tidak bisa melayani request tanpanya.
  • Untuk dependency eksternal non-kritis, pertimbangkan apakah sebaiknya memengaruhi readiness atau hanya dicatat sebagai degraded.
  • Pastikan endpoint health tidak melakukan query berat atau memicu efek samping.

Jika Anda butuh indikator kesehatan kustom, buat komponen yang ringan dan deterministik. Hindari health check yang memperburuk beban saat sistem sudah sedang bermasalah.

Migrasi database yang aman untuk blue-green

Bagian tersulit dari blue-green deployment sering kali bukan pada aplikasi, melainkan pada skema database. Karena blue dan green bisa hidup bersamaan, perubahan skema harus kompatibel dengan kedua versi setidaknya selama masa transisi.

Gunakan pola expand and contract

Pendekatan aman biasanya mengikuti urutan berikut:

  1. Expand: tambahkan kolom, tabel, indeks, atau struktur baru tanpa menghapus yang lama.
  2. Deploy aplikasi baru yang dapat membaca/menulis dengan skema lama dan baru bila perlu.
  3. Setelah seluruh trafik stabil di versi baru dan data tervalidasi, lakukan fase contract: hapus kolom atau perilaku lama.

Contoh perubahan yang relatif aman:

  • Menambah kolom nullable.
  • Menambah tabel baru.
  • Menambah indeks untuk query baru.

Contoh perubahan berisiko tinggi saat blue dan green aktif bersamaan:

  • Mengganti nama kolom yang masih dipakai versi lama.
  • Mengubah tipe data secara destruktif.
  • Menghapus kolom lama sebelum semua instance lama dihentikan.

Praktik migrasi

  • Jalankan migrasi dengan tool yang terkontrol dan dapat diaudit.
  • Pisahkan migrasi skema dari migrasi data berat bila memungkinkan.
  • Uji migrasi pada data yang menyerupai produksi, terutama untuk tabel besar.
  • Pastikan rollback aplikasi tidak bergantung pada rollback skema destruktif.

Catatan penting: rollback aplikasi lebih mudah daripada rollback data. Jika versi baru sudah menulis data dalam format yang tidak dipahami versi lama, mengembalikan trafik ke blue bisa gagal secara fungsional meskipun service hidup.

Urutan langkah blue-green deployment Spring Boot

Berikut alur deploy yang praktis dan cukup aman untuk tim backend:

  1. Build artifact dan jalankan test otomatis.
  2. Deploy ke green tanpa menerima trafik produksi penuh.
  3. Jalankan migrasi database yang kompatibel atau pastikan sudah dijalankan sebelumnya.
  4. Verifikasi startup: cek log, actuator health, readiness, koneksi database, dan dependency utama.
  5. Smoke test ke green: endpoint penting, auth, write path, dan query utama.
  6. Cutover trafik ke green, idealnya bertahap jika sistem routing mendukung.
  7. Pantau sinyal error selama beberapa menit pertama: error rate, latency, saturation, log exception, dan health status.
  8. Rollback ke blue bila indikator melewati ambang yang sudah ditentukan.
  9. Promosikan green menjadi aktif setelah stabil; blue tetap dipertahankan sementara sebagai kandidat rollback cepat.

Contoh checklist verifikasi sebelum cutover

  • Endpoint health mengembalikan status siap.
  • Koneksi database berhasil dan pool koneksi stabil.
  • Endpoint login atau autentikasi utama lolos.
  • Minimal satu alur baca dan satu alur tulis lolos.
  • Tidak ada lonjakan exception saat warm-up.
  • Konfigurasi environment green sesuai produksi.
  • Dashboard log dan metric untuk versi baru sudah tersedia.

Sinyal error yang perlu dipantau setelah rilis

Rollback sebaiknya dipicu oleh sinyal yang objektif, bukan rasa panik atau satu log error yang belum tentu relevan. Tim perlu mendefinisikan indikator sebelum deploy dimulai.

Indikator umum untuk memicu rollback

  • Error rate HTTP 5xx meningkat signifikan dibanding baseline normal.
  • Latency p95 atau p99 naik tajam pada endpoint utama.
  • Readiness sering gagal pada beberapa instance green.
  • Lonjakan exception berulang pada log, misalnya timeout database, deadlock, atau serialization error.
  • Consumer lag meningkat pada worker async yang terkait dengan rilis.
  • Resource saturation seperti CPU, memory, atau connection pool mencapai batas dan berdampak ke request.

Contoh aturan keputusan rollback

Hindari aturan yang terlalu kabur seperti “kalau error banyak maka rollback”. Buat runbook yang eksplisit. Contohnya:

  • Rollback jika endpoint inti mengalami kenaikan error 5xx yang konsisten selama beberapa menit setelah cutover.
  • Rollback jika readiness gagal berulang pada lebih dari satu instance green.
  • Rollback jika latency endpoint pembayaran atau checkout meningkat tajam dan disertai keluhan pengguna atau timeout upstream.
  • Jangan rollback hanya karena satu exception tunggal yang tidak memengaruhi alur utama.

Angka pastinya harus ditentukan berdasarkan baseline layanan Anda. Yang terpenting adalah ambang, durasi observasi, dan penanggung jawab keputusan ditulis jelas sebelum deploy.

Observabilitas dasar: log, metric, dan alert

Tanpa observabilitas, blue-green deployment hanya memindahkan risiko dari downtime ke kebingungan saat insiden. Tiga pilar minimum yang perlu ada adalah log terstruktur, metrik aplikasi, dan alert yang masuk akal.

Log

  • Gunakan format log terstruktur bila memungkinkan.
  • Sertakan request id, trace id, nama service, environment, dan versi release.
  • Pastikan exception penting tidak tertelan oleh handler yang terlalu generik.

Menambahkan identifier versi pada log akan membantu membedakan error dari blue dan green saat keduanya berjalan bersamaan.

Metric

Minimal pantau:

  • Request count per endpoint atau grup endpoint.
  • Error count dan error rate.
  • Latency distribusi, terutama p95/p99.
  • JVM memory, GC, thread, CPU.
  • Database connection pool usage.
  • Status readiness/liveness.

Jika aplikasi mengekspose metrik melalui actuator, integrasikan ke sistem monitoring yang dipakai tim. Tidak harus vendor tertentu; yang penting dashboard rilis bisa membandingkan blue dan green dengan cepat.

Alert

Alert harus relevan dengan tindakan. Beberapa contoh:

  • Readiness gagal terus-menerus setelah deploy.
  • Error rate endpoint inti meningkat di atas baseline.
  • Latency tinggi disertai timeout upstream atau database.
  • Pool koneksi penuh atau thread pool kehabisan kapasitas.

Kesalahan umum adalah membuat terlalu banyak alert berbasis gejala yang tidak bisa ditindaklanjuti. Saat deploy, fokus pada alert yang mendukung keputusan: lanjutkan, tahan trafik, atau rollback.

Contoh implementasi pipeline dan verifikasi sederhana

Berikut contoh alur shell generik untuk menggambarkan proses, bukan skrip final siap produksi:

# 1. Deploy artifact ke environment green
./deploy-green.sh

# 2. Tunggu endpoint readiness siap
curl -fsS http://green-app/actuator/health/readiness

# 3. Jalankan smoke test penting
./smoke-test.sh http://green-app

# 4. Alihkan trafik ke green
./switch-traffic.sh green

# 5. Pantau sinyal beberapa menit
./watch-release-metrics.sh

# 6. Jika error naik, rollback ke blue
./switch-traffic.sh blue

Dalam praktik nyata, tiap langkah biasanya diperkaya dengan validasi otomatis, approval manual, dan pencatatan release version. Yang penting adalah alur ini repeatable dan tidak bergantung pada ingatan satu orang.

Pencegahan risiko: feature flag, deployment bertahap, dan runbook

Feature flag

Feature flag berguna untuk memisahkan deploy dari release. Artinya, kode baru sudah ada di green, tetapi fitur yang berisiko masih dimatikan. Jika infrastruktur rilis sukses namun fitur tertentu bermasalah, Anda bisa mematikan fitur tanpa rollback seluruh aplikasi.

Namun, feature flag juga menambah kompleksitas. Tim perlu disiplin membersihkan flag yang sudah tidak dipakai dan mendokumentasikan kombinasi state yang didukung.

Deployment bertahap

Meskipun topiknya blue-green, pengalihan trafik tidak harus langsung 100%. Jika platform routing mendukung, mulailah dengan sebagian kecil trafik ke green untuk melihat sinyal awal. Ini membantu mendeteksi masalah yang tidak muncul saat smoke test.

Jika routing bertahap tidak tersedia, setidaknya lakukan cutover pada jam dengan risiko operasional yang terukur dan tim siaga lengkap.

Runbook

Runbook deploy dan rollback harus singkat, operasional, dan mudah dieksekusi saat tekanan tinggi. Isi minimalnya:

  • Prasyarat sebelum deploy.
  • Perintah atau langkah deploy ke green.
  • Cara verifikasi readiness dan smoke test.
  • Dashboard dan query log yang harus dibuka.
  • Kriteria rollback yang disepakati.
  • Langkah rollback dan verifikasi pasca-rollback.
  • Kontak penanggung jawab aplikasi, database, dan infrastruktur.

Checklist verifikasi pasca-rilis

Setelah trafik pindah ke green, jangan berhenti pada status “deploy sukses”. Lakukan verifikasi pasca-rilis berikut:

  • Traffic benar-benar masuk ke green sesuai ekspektasi.
  • Error rate stabil dan tidak ada lonjakan exception baru.
  • Latency endpoint utama tetap dalam rentang normal.
  • Readiness dan liveness seluruh instance stabil.
  • Koneksi database, cache, dan broker tidak mendekati batas.
  • Fitur utama yang baru dirilis berfungsi di jalur nyata.
  • Tidak ada backlog async atau job gagal yang meningkat.
  • Alert kritis tetap bersih selama masa observasi.

Contoh insiden kecil dan postmortem ringan

Misalkan tim merilis versi green yang menambahkan query baru untuk endpoint laporan. Deploy berhasil, health check hijau, dan smoke test lolos. Setelah cutover penuh, dalam beberapa menit latency endpoint laporan melonjak dan mulai muncul timeout database. Error rate 5xx memang belum tinggi, tetapi pool koneksi naik tajam dan alert latency aktif.

Keputusan saat insiden

  1. Tim melihat masalah hanya muncul di green berdasarkan label versi pada dashboard.
  2. Karena endpoint tersebut termasuk alur penting bagi pengguna internal, trafik segera dikembalikan ke blue.
  3. Setelah rollback, latency normal kembali dan alert mereda.

Temuan postmortem singkat

  • Query baru tidak memiliki indeks yang memadai pada data produksi.
  • Smoke test hanya memverifikasi status respons, bukan performa query.
  • Readiness tidak mendeteksi masalah karena aplikasi memang sehat secara proses.

Tindakan perbaikan

  • Tambahkan indeks melalui migrasi yang aman.
  • Buat uji verifikasi query plan atau load test ringan pada endpoint sensitif.
  • Tambahkan panel observabilitas khusus release untuk latency endpoint utama.
  • Perbarui runbook agar cutover diawali trafik parsial jika memungkinkan.

Pelajaran pentingnya: health check bukan pengganti observabilitas performa. Aplikasi bisa sehat secara teknis tetapi tetap gagal memenuhi kebutuhan pengguna karena lambat.

Kesalahan umum yang sering terjadi

  • Menganggap proses startup sukses berarti aplikasi siap menerima trafik.
  • Menjalankan migrasi database yang tidak kompatibel dengan versi lama.
  • Tidak memberi label versi release pada log dan metric.
  • Tidak mendefinisikan ambang rollback sebelum deploy.
  • Mengandalkan rollback aplikasi padahal data sudah berubah tidak kompatibel.
  • Tidak menguji alur tulis, hanya endpoint health dan endpoint baca.
  • Runbook terlalu panjang atau hanya dipahami satu orang.

Penutup

Blue-green deployment Spring Boot memberi jalur rilis yang lebih aman jika dibangun di atas tiga fondasi: health check yang benar, migrasi database yang kompatibel, dan observabilitas yang cukup untuk mendeteksi sinyal error sejak awal. Rollback cepat bukan hasil kebetulan, melainkan hasil desain operasional yang sadar risiko.

Mulailah dari hal yang paling berdampak: siapkan actuator health yang membedakan readiness dan liveness, buat runbook deploy-rollback yang eksplisit, definisikan indikator rollback yang objektif, lalu pastikan perubahan database mengikuti pola yang aman untuk dua versi aplikasi. Dengan itu, blue-green deployment bukan sekadar istilah DevOps, tetapi proses rilis yang benar-benar membantu tim backend Java menjaga stabilitas produksi.