Strategi Deployment Anda Sudah Menentukan Seberapa Sulit Pemulihan Nanti

Kebanyakan tim menganggap pemulihan sebagai sesuatu yang mereka cari tahu setelah sesuatu rusak. Mereka menulis skrip rollback, menyimpan cadangan artefak lama, dan berharap tidak pernah membutuhkannya. Namun kenyataannya, bagian tersulit dari pemulihan bukanlah rollback itu sendiri. Melainkan situasi yang Anda hadapi saat menyadari bahwa Anda tidak bisa melakukan rollback dengan bersih karena cara Anda melakukan deployment sejak awal.

Pikirkan skenario ini. Tim Anda mendorong versi baru ke produksi. Semua server diganti sekaligus. Versi lama mati, versi baru muncul, setiap pengguna sekarang menggunakan kode baru. Kemudian alert monitoring mulai berbunyi. Ada yang salah. Satu-satunya pilihan Anda adalah rollback penuh. Setiap server, setiap pengguna, setiap koneksi. Tidak ada jalan tengah. Anda sepenuhnya menggunakan versi yang rusak atau sepenuhnya menggunakan versi lama. Dan saat Anda melakukan rollback itu, setiap pengguna sedang mengalami masalah.

Sekarang bandingkan dengan tim yang menggunakan deployment blue-green. Mereka memiliki dua lingkungan yang identik. Satu lingkungan aktif dan melayani pengguna. Lingkungan lainnya memiliki versi baru yang siap. Saat waktunya rilis, mereka cukup mengalihkan traffic dari lingkungan biru ke lingkungan hijau. Jika terjadi kesalahan, mereka mengalihkan traffic kembali. Lingkungan lama masih berjalan. Rollback hanya membutuhkan waktu detik. Tidak ada perubahan kode, tidak ada perubahan konfigurasi, tidak ada menunggu pipeline selesai.

Perbedaannya bukan tentang memiliki skrip rollback yang lebih baik. Perbedaannya adalah tentang memilih strategi deployment yang membatasi radius ledakan sebelum terjadi kesalahan.

Deployment Blue-Green Membuat Pemulihan Hampir Instan

Deployment blue-green bukan sekadar pola mewah untuk rilis tanpa downtime. Ini adalah mekanisme pemulihan yang menyamar sebagai strategi deployment. Wawasan utamanya adalah Anda menjaga lingkungan lama tetap berjalan sampai Anda yakin lingkungan baru berfungsi. Jika versi baru gagal, Anda tidak perlu membangun ulang apa pun. Anda cukup mengarahkan traffic kembali ke lingkungan lama.

Ini bekerja dengan baik untuk aplikasi stateless di mana lingkungan hanyalah komputasi dan konfigurasi. Namun ini menjadi lebih rumit ketika Anda memiliki perubahan skema database. Jika versi baru menjalankan migrasi yang mengubah struktur database, versi lama mungkin tidak akan berfungsi dengan skema baru. Dalam kasus itu, mengalihkan traffic kembali saja tidak cukup. Anda juga perlu mengembalikan migrasi database, yang memakan waktu dan membawa risikonya sendiri.

Berikut adalah konfigurasi Service Kubernetes minimal yang memungkinkan peralihan tersebut. Selector menunjuk ke lingkungan aktif, dan mengubahnya dari blue ke green (atau sebaliknya) akan mengarahkan ulang semua traffic secara instan.

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
    environment: blue   # ganti ke 'green' untuk rollback
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Ketika versi baru gagal, Anda perbarui selector menjadi environment: green dan terapkan perubahannya. Tidak perlu rebuild, tidak perlu menunggu pipeline — hanya pembaruan satu field.

Kesimpulan praktisnya adalah deployment blue-green memberi Anda jalur rollback yang cepat, tetapi hanya jika Anda menjaga lingkungan lama tetap kompatibel dengan state database saat ini. Jika Anda tidak bisa menjamin itu, rollback Anda tidak instan. Itu hanya lebih cepat daripada membangun dari awal.

Deployment Canary Membatasi Jumlah Pengguna yang Terdampak

Deployment canary mengambil pendekatan yang berbeda. Alih-alih mengalihkan semua traffic sekaligus, Anda mengirim persentase kecil pengguna ke versi baru. Mungkin lima persen. Jika grup itu tidak menunjukkan masalah, Anda meningkatkan persentasenya secara bertahap sampai semua pengguna menggunakan versi baru.

Keuntungan pemulihan di sini jelas. Jika versi baru memiliki masalah, hanya lima persen pengguna yang terpengaruh. Anda dapat menghentikan canary, mengirim pengguna tersebut kembali ke versi lama, dan menyelidiki masalah tanpa tekanan untuk memperbaiki semuanya segera. Radius ledakannya kecil secara desain.

Deployment canary bekerja dengan baik ketika Anda memiliki cukup traffic untuk mendeteksi masalah di grup kecil dan ketika infrastruktur Anda dapat menangani menjalankan dua versi secara berdampingan. Ini juga membutuhkan observabilitas yang baik. Anda perlu membandingkan tingkat error, latensi, dan perilaku pengguna antara grup canary dan grup kontrol. Tanpa itu, Anda hanya menebak-nebak apakah versi baru aman untuk dirilis lebih lanjut.

Konsekuensinya adalah kompleksitas. Anda membutuhkan logika routing traffic, monitoring yang dapat membandingkan grup, dan proses untuk memutuskan kapan harus meningkatkan persentase canary. Namun bagi tim yang sering melakukan deploy dan tidak mampu melakukan rollback penuh, kompleksitas ini sepadan.

Feature Flags Memungkinkan Anda Pulih Tanpa Melakukan Deployment Apa Pun

Feature flags bekerja berbeda dari strategi lainnya. Alih-alih men-deploy versi baru untuk mengontrol siapa yang melihatnya, Anda men-deploy kode baru ke semua orang tetapi menyembunyikannya di balik saklar. Kode sudah ada di produksi. Hanya saja belum aktif untuk pengguna. Anda menyalakan saklar untuk grup kecil, memantau hasilnya, lalu memperluas audiens secara bertahap.

Jika terjadi kesalahan, Anda mematikan saklar. Tidak ada rollback, tidak ada hotfix, tidak ada menunggu pipeline. Pemulihan terjadi dalam hitungan detik dengan satu perubahan konfigurasi. Ini adalah pendekatan paling bedah untuk membatasi radius ledakan. Anda dapat mengaktifkan fitur untuk pengguna internal terlebih dahulu, lalu pengguna beta, lalu persentase traffic produksi, dan akhirnya semua orang. Kapan saja, Anda dapat menonaktifkan fitur secara instan.

Feature flags sangat kuat, tetapi memiliki biaya tersendiri. Anda memerlukan sistem untuk mengelola flag, proses untuk membersihkan flag lama, dan disiplin untuk menghindari flag yang tidak terkendali. Setiap flag dalam kode Anda menambahkan logika kondisional yang membuat pengujian lebih sulit. Jika Anda tidak pernah menghapus flag setelah fitur stabil, basis kode Anda menjadi labirin cabang yang mati.

Nilai sebenarnya dari feature flags bukanlah tentang pengiriman yang lebih cepat. Ini tentang memiliki mekanisme pemulihan yang tidak memerlukan deployment sama sekali. Itu mengubah profil risiko dari setiap rilis.

Strategi Deployment Anda Adalah Rencana Pemulihan Anda

Inilah ide inti yang menghubungkan semuanya. Anda tidak dapat memisahkan strategi deployment dari rencana pemulihan Anda. Keputusan yang Anda buat tentang cara merilis versi baru menentukan opsi pemulihan apa yang Anda miliki ketika terjadi kesalahan.

Diagram di bawah menunjukkan bagaimana setiap strategi menangani kegagalan, dari deteksi hingga pemulihan.

flowchart TD A[Deploy versi baru] --> B{Strategi deployment?} B -->|Blue-Green| C[Alihkan traffic ke env baru] C --> D{Versi baru gagal?} D -->|Ya| E[Alihkan traffic kembali ke env lama] D -->|Tidak| F[Pertahankan env baru tetap aktif] B -->|Canary| G[Arahkan 5% traffic ke versi baru] G --> H{Ada error di canary?} H -->|Ya| I[Hentikan canary, kirim pengguna kembali] H -->|Tidak| J[Tingkatkan traffic secara bertahap] B -->|Feature Flags| K[Deploy kode tersembunyi di balik flag] K --> L[Aktifkan flag untuk grup kecil] L --> M{Masalah terdeteksi?} M -->|Ya| N[Nonaktifkan flag secara instan] M -->|Tidak| O[Perluas audiens flag]

Jika Anda melakukan deploy dengan mengganti semua server sekaligus, satu-satunya opsi pemulihan Anda adalah rollback penuh. Jika Anda menggunakan blue-green, Anda memiliki peralihan instan. Jika Anda menggunakan canary, Anda membatasi jumlah pengguna yang terpengaruh. Jika Anda menggunakan feature flags, Anda dapat menonaktifkan fitur yang bermasalah tanpa menyentuh pipeline deployment.

Setiap strategi memiliki konsekuensi. Blue-green membutuhkan infrastruktur dua kali lipat. Canary membutuhkan monitoring yang baik dan routing traffic. Feature flags membutuhkan sistem manajemen flag dan disiplin pembersihan. Namun semuanya lebih baik daripada tidak memiliki strategi dan berharap skrip rollback berfungsi saat Anda membutuhkannya.

Tim yang pulih paling cepat bukanlah tim dengan skrip rollback terbaik. Mereka adalah tim yang mendesain proses deployment mereka untuk membuat pemulihan menjadi mudah sejak awal.

Daftar Periksa Cepat untuk Deployment Anda Berikutnya

  • Dapatkah Anda melakukan rollback tanpa mengubah kode atau konfigurasi?
  • Berapa banyak pengguna yang akan terpengaruh jika versi baru gagal?
  • Dapatkah Anda menguji versi baru di produksi tanpa mengekspos semua pengguna?
  • Apakah Anda memiliki cara untuk menonaktifkan fitur tertentu tanpa melakukan redeploy?
  • Apakah lingkungan lama Anda masih berjalan dan kompatibel dengan database saat ini?

Jika Anda menjawab tidak untuk sebagian besar pertanyaan ini, pemulihan Anda berikutnya akan lebih sulit dari yang seharusnya.

Artinya bagi Tim Anda

Lain kali Anda merencanakan deployment, jangan hanya berpikir tentang cara menaikkan versi baru. Pikirkan tentang cara menurunkannya jika terjadi kesalahan. Pilih strategi yang memberi Anda opsi. Diri Anda di masa depan, yang berdiri di depan dashboard penuh alert merah, akan berterima kasih.