Kenapa Rilis Bertahap Itu Lebih Penting dari yang Kamu Kira

Tim kamu baru saja menghabiskan dua minggu menyelesaikan fitur baru. Kode sudah di-review. Tes lulus di staging. Semua terlihat baik. Kamu menjalankan pipeline, versi baru dikirim ke semua server, dan setiap pengguna langsung mendapatkan fitur baru itu.

Lima menit kemudian, tingkat error mulai naik. Sepuluh menit kemudian, pengguna melaporkan tidak bisa mengakses halaman utama. Kamu panik, menekan tombol rollback, dan semua orang kembali ke versi lama. Tapi kerusakan sudah terjadi: beberapa pengguna kehilangan data sementara, yang lain mengalami error, dan kepercayaan terhadap aplikasi kamu menurun.

Masalahnya bukan karena kode yang buruk. Masalahnya adalah cara kamu mengirimkannya. Ketika setiap perubahan dikirim ke semua pengguna pada waktu yang sama, kamu tidak punya celah untuk melihat apakah versi baru benar-benar berfungsi di produksi. Kamu tidak punya kesempatan untuk memeriksa dampak sebelum semua orang terpengaruh.

Ini yang disebut dengan big bang release. Semua perubahan dikirim sekaligus, ke semua pengguna, tanpa jeda untuk observasi. Ini membawa risiko yang sulit dihindari.

Kenapa Staging Saja Tidak Cukup

Lingkungan staging tidak pernah benar-benar cocok dengan produksi. Perbedaan konfigurasi, pola lalu lintas, dan data pengguna nyata menciptakan celah yang hanya muncul di produksi. Tes kamu mungkin solid, tapi tes berjalan dengan data sintetis dan perilaku simulasi. Pengguna nyata melakukan hal-hal yang tidak terduga.

Pengguna yang berbeda juga memiliki pola penggunaan yang berbeda. Fitur yang berfungsi baik untuk satu grup mungkin rusak untuk grup lain. Pengguna power user mencapai edge cases yang tidak pernah dipicu oleh pengguna biasa. Pengguna mobile memiliki kondisi jaringan yang berbeda dengan pengguna desktop. Rilis tunggal memperlakukan semua orang sama, tapi pengguna kamu tidak sama.

Ketika ada yang salah dengan big bang release, radius ledakannya sangat besar. Setiap pengguna terekspos. Setiap sesi terpengaruh. Tekanan untuk memperbaikinya segera sangat intens, yang mengarah pada keputusan terburu-buru dan lebih banyak kesalahan.

Alternatifnya: Progressive Delivery

Alih-alih mengirim versi baru ke semua orang sekaligus, kirim secara bertahap. Mulai dengan persentase kecil pengguna. Amati apa yang terjadi. Jika semuanya terlihat baik, perluas jangkauan. Jika ada yang salah, hanya grup kecil yang terpengaruh.

Progressive delivery bukanlah satu teknik. Ini adalah kombinasi dari praktik-praktik:

Diagram alir berikut mengilustrasikan bagaimana rilis bertahap bekerja, dengan pemeriksaan otomatis di setiap langkah:

flowchart TD A[Mulai: 1% pengguna] --> B[Pantau metrik] B --> C{Semua hijau?} C -->|Ya| D[Tingkatkan ke 5%] D --> E[Pantau metrik] E --> F{Semua hijau?} F -->|Ya| G[Tingkatkan ke 10%] G --> H[Pantau metrik] H --> I{Semua hijau?} I -->|Ya| J[Tingkatkan ke 25%] J --> K[Pantau metrik] K --> L{Semua hijau?} L -->|Ya| M[Tingkatkan ke 50%] M --> N[Pantau metrik] N --> O{Semua hijau?} O -->|Ya| P[Rilis 100%] C -->|Tidak| Q[Jeda atau rollback] F -->|Tidak| Q I -->|Tidak| Q L -->|Tidak| Q O -->|Tidak| Q
  • Mengontrol persentase lalu lintas yang mendapatkan versi baru
  • Memutuskan pengguna mana yang melihat perubahan terlebih dahulu
  • Menyalakan atau mematikan fitur untuk grup tertentu
  • Memantau metrik secara real-time
  • Membuat keputusan otomatis berdasarkan data yang terkumpul

Tujuannya sederhana: mengurangi risiko dengan membatasi eksposur. Ketika rilis buruk hanya mengenai 5% pengguna, masalahnya masih bisa dikelola. Kamu punya waktu untuk menganalisis, memutuskan apakah akan memperbaiki atau rollback, dan bertindak tanpa panik.

Apa yang Kamu Kontrol Selama Rilis Bertahap

Progressive delivery memberi kamu beberapa tuas yang bisa ditarik selama rilis. Memahami masing-masing membantu kamu merancang strategi yang sesuai dengan situasi.

Pengalihan lalu lintas mengontrol seberapa banyak lalu lintas pengguna yang mencapai versi baru. Kamu bisa mulai dengan 1% lalu lintas, lalu naik ke 5%, 20%, 50%, dan akhirnya 100%. Setiap langkah memberi kamu data sebelum meningkatkan eksposur.

Penargetan pengguna memungkinkan kamu memilih siapa yang mendapatkan versi baru terlebih dahulu. Pengguna internal, beta tester, atau pengguna di wilayah tertentu bisa menjadi pengadopsi awal. Ini memberi kamu umpan balik dari grup yang terkontrol sebelum rilis yang lebih luas.

Feature flags memisahkan deployment dari rilis. Kamu bisa men-deploy kode dengan fitur baru yang dimatikan, lalu mengaktifkannya secara bertahap. Jika ada yang salah, kamu mematikan flag tanpa harus rollback seluruh deployment.

Environment gating berarti kamu tidak langsung melompat ke produksi. Kamu mungkin rilis ke canary environment terlebih dahulu, lalu subset produksi kecil, lalu produksi yang lebih luas. Setiap lingkungan menambah kepercayaan diri.

Metrik yang Penting Selama Progressive Delivery

Rilis bertahap hanya membantu jika kamu memantau sinyal yang tepat. Tanpa monitoring, kamu terbang buta.

Tingkat error adalah metrik yang paling jelas. Lonjakan error 5xx atau exception sisi klien berarti ada yang salah. Tapi jangan hanya melihat tingkat keseluruhan. Bandingkan tingkat error antara versi baru dan versi lama. Tingkat error 0,5% mungkin terlihat baik sampai kamu melihat versi lama berjalan di 0,05%.

Waktu respons sering menurun sebelum error muncul. Jika versi baru lebih lambat, pengguna mungkin tidak langsung mengeluh, tapi mereka akan menyadarinya. Lacak latensi p95 dan p99, bukan hanya rata-rata.

Metrik bisnis memberi tahu kamu apakah fitur tersebut benar-benar berfungsi. Tingkat konversi, pendaftaran, pembelian, atau metrik keterlibatan menunjukkan apakah perubahan memberikan nilai. Rilis yang sempurna secara teknis tetapi merusak metrik bisnis tetaplah rilis yang buruk.

Masalah yang dilaporkan pengguna lebih lambat tetapi berharga. Pantau tiket dukungan, sebutan di media sosial, dan laporan internal. Terkadang pengguna melihat masalah yang terlewatkan oleh monitoring otomatis.

Membangun Pipeline yang Memutuskan Sendiri

Pipeline progressive delivery yang paling efektif tidak menunggu manusia membuat setiap keputusan. Mereka mengotomatiskan pemeriksaan go/no-go berdasarkan metrik.

Begini cara kerjanya dalam praktik:

Berikut contoh konkret menggunakan Argo Rollouts, sebuah controller Kubernetes yang mengotomatiskan proses ini:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-service
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: {duration: 10m}
        - analysis:
            templates:
            - templateName: success-rate
            args:
            - name: service-name
              value: my-service
        - setWeight: 20
        - pause: {duration: 10m}
        - analysis:
            templates:
            - templateName: success-rate
        - setWeight: 50
        - pause: {duration: 10m}
        - analysis:
            templates:
            - templateName: success-rate
        - setWeight: 100

Konfigurasi ini secara bertahap mengalihkan lalu lintas dari 5% ke 100%, berhenti sejenak setelah setiap langkah untuk menjalankan pemeriksaan analisis otomatis. Jika tingkat keberhasilan turun di bawah ambang batas, rollout secara otomatis berhenti atau rollback.

  1. Pipeline men-deploy versi baru ke subset kecil server atau pengguna
  2. Sistem monitoring mengumpulkan metrik untuk periode yang ditentukan (misalnya 10 menit)
  3. Pemeriksaan otomatis membandingkan metrik dengan ambang batas
  4. Jika metrik sehat, pipeline meningkatkan persentase rollout
  5. Jika metrik melampaui ambang batas, pipeline berhenti atau rollback secara otomatis

Ini menghilangkan penundaan manusia antara mendeteksi masalah dan bertindak. Saat kamu tidur atau sedang rapat, pipeline terus melindungi pengguna kamu.

Ambang batas perlu diatur dengan hati-hati. Terlalu ketat, dan kamu akan mendapatkan false positive yang memblokir rilis. Terlalu longgar, dan kamu akan melewatkan masalah nyata. Mulailah dengan ambang batas konservatif dan sesuaikan berdasarkan pengalaman.

Daftar Periksa Praktis untuk Rilis Bertahap Berikutnya

Sebelum kamu menerapkan progressive delivery, jalankan daftar periksa ini:

  • Bisakah kamu merutekan lalu lintas ke versi tertentu dari aplikasi kamu?
  • Apakah kamu memiliki monitoring real-time untuk tingkat error, latensi, dan metrik bisnis?
  • Sudahkah kamu menentukan ambang batas yang jelas untuk setiap metrik?
  • Bisakah kamu melakukan rollback rilis parsial tanpa memengaruhi pengguna di versi lama?
  • Apakah kamu memiliki cara untuk menargetkan grup pengguna tertentu (internal, beta, berdasarkan wilayah)?
  • Apakah pipeline kamu mampu berhenti atau rollback secara otomatis?
  • Sudahkah kamu menguji proses progressive delivery di lingkungan non-produksi?

Intisari

Big bang release mengubah setiap deployment menjadi perjudian. Kamu bertaruh bahwa tes staging menangkap semuanya, bahwa produksi akan berperilaku persis seperti lingkungan pengujian, dan bahwa semua pengguna kamu akan memiliki pengalaman yang sama. Taruhan itu lebih sering gagal daripada yang diakui tim.

Progressive delivery mengubah persamaan. Alih-alih mempertaruhkan semuanya pada satu rilis, kamu memasang taruhan kecil dan memeriksa hasilnya sebelum bertaruh lebih banyak. Ketika ada yang salah, kerusakannya terbatas. Tim kamu tetap tenang, pengguna kamu tetap senang, dan proses rilis kamu menjadi sesuatu yang kamu percayai, bukan sesuatu yang kamu takuti.

Mulailah dari yang kecil. Pilih satu service atau satu fitur. Siapkan pengalihan lalu lintas dan monitoring. Jalankan rilis berikutnya melalui proses bertahap. Keyakinan yang kamu dapatkan akan membuatmu bertanya-tanya mengapa kamu pernah mengirim dengan cara lain.