# Apa Itu Progressive Delivery? Canary, Blue-Green, Flag URL: https://codebasechat.com/id/journal/apa-itu-progressive-delivery Type: blog Locale: id Published: 2026-11-03 Updated: 2026-11-03 --- > Progressive delivery merilis perubahan dalam langkah kecil yang diperiksa metrik. Berikut cara canary, blue-green dan feature flag saling melengkapi, serta titik awal yang realistis. Apa itu progressive delivery? Ini cara merilis perangkat lunak ketika perubahan masuk ke produksi dalam langkah kecil yang terkontrol, dan setiap langkah dicek terhadap metrik nyata sebelum langkah berikutnya dimulai. Jika angkanya memburuk, rilis berhenti atau kembali secara otomatis. Anda tidak lagi mempertaruhkan seluruh pengguna pada satu kali deploy. Mungkin Anda sudah kenal situasinya. Pull request disetujui, CI hijau, deploy berjalan Selasa sore, dan dua puluh menit kemudian seseorang di Slack bertanya kenapa latensi checkout naik dua kali lipat. Progressive delivery membuat percakapan seperti itu lebih singkat, dan membuat masalahnya hanya menyentuh 5% traffic, bukan 100%. ## Apa yang sebenarnya berubah dengan progressive delivery? Continuous delivery menjawab satu pertanyaan: apakah perubahan ini aman dikirim ke produksi? Progressive delivery menambahkan pertanyaan kedua: siapa yang melihatnya lebih dulu, dan apa yang memberi tahu kita untuk berhenti? Intinya adalah memisahkan **deploying** dari **releasing**. Deploying berarti kode baru sudah berjalan di server. Releasing berarti pengguna mulai terpapar kode itu. Setelah keduanya terpisah, Anda bisa melakukan deploy pada Rabu siang dan merilis sesuai ritme Anda, ke audiens yang dipilih, dengan jalan kembali yang jelas. Sebagian besar sumber sepakat pada tiga blok bangunan: pergeseran traffic bertahap (canary), lingkungan paralel (blue-green), dan feature flag. Ketiganya bukan saingan. Tim yang sudah matang memakai ketiganya di lapisan yang berbeda. ## Canary release: berapa traffic, dan siapa yang memutuskan? Canary release mengirim sebagian kecil traffic ke versi baru, misalnya 5%, sementara sisanya tetap di versi lama. Jika error rate, latensi, dan saturasi tetap berada dalam ambang batas Anda, porsinya membesar: 5%, 25%, 50%, lalu 100%. Jika tidak, traffic kembali ke versi lama. Masalahnya, pembagian traffic yang presisi membutuhkan komponen yang memang bisa membagi traffic. [Dokumentasi Argo Rollouts](https://argo-rollouts.readthedocs.io/en/stable/concepts/) menyebutkan bahwa persentase canary yang presisi memerlukan traffic manager seperti service mesh atau ingress controller. Tanpa itu, kontrolnya kasar dan hanya berbasis jumlah replika, sehingga "5%" bisa berarti "satu pod dari dua puluh". Berikut contoh manifes canary bertahap di Argo Rollouts. Sengaja dibuat pendek. `strategy: canary: steps: - setWeight: 5 - pause: { duration: 10m } # pantau dashboard atau jalankan analisis - setWeight: 25 - pause: { duration: 10m } - setWeight: 100`Lewati canary jika layanan Anda menerima traffic sangat sedikit, sehingga 5% hanya berarti beberapa request per jam. Anda akan menunggu sinyal tanpa henti, atau yang lebih buruk, membaca noise sebagai rasa aman. Untuk layanan dengan traffic rendah, feature flag yang ditargetkan ke pengguna internal biasanya menjadi gerbang pertama yang lebih baik. ![Tiga toples berisi pasir biru dengan ketinggian berbeda, melambangkan persentase traffic bertahap](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/97a746-i1.webp) ## Blue-green deployment: kapan dua environment penuh layak dipakai? Blue-green menjalankan dua environment produksi yang lengkap. Blue melayani pengguna. Green menerima versi baru dan diuji saat belum melayani siapa pun. Setelah hasilnya memuaskan, traffic dipindahkan dari satu ke yang lain. Menurut dokumentasi Argo Rollouts, perpindahannya dilakukan sekaligus: versi lama tetap memegang seluruh traffic produksi sampai versi baru terverifikasi, lalu pembagiannya berpindah dari 0% ke 100%. Di situlah kekuatan sekaligus kelemahannya. Rollback cukup dengan satu kali balik, jadi cepat. Namun pengujian terjadi sebelum pengguna sungguhan datang, dan biayanya dua kali lipat infrastruktur selama kedua sisi berjalan. Layak dipakai untuk layanan stateful atau layanan dengan taruhan tinggi, di mana rilis sebagian akan membingungkan. Contohnya jalur pembayaran yang tidak boleh melayani request dengan dua versi sekaligus. Lewati pendekatan ini jika migrasi database Anda tidak bisa berjalan di kedua versi sekaligus, karena "rollback instan" di situ hanyalah fiksi. ![Dua rel kereta paralel dengan tuas wesel, melambangkan lingkungan blue-green](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/aba476-i2.webp) ## Di mana feature flag cocok? Canary dan blue-green bekerja di level infrastruktur. Feature flag bekerja di dalam aplikasi. Flag membungkus sebuah jalur kode dengan kondisi yang bisa diubah saat runtime, tanpa redeploy. Itu membuat flag menjadi alat paling granular. Anda bisa membuka sebuah fitur untuk karyawan, lalu untuk 1% akun, lalu untuk satu segmen pelanggan, dan mematikannya dalam hitungan detik jika bermasalah. Sebagian tim memperlakukan flag sebagai salah satu teknik di antara beberapa lainnya, sementara yang lain menganggapnya sebagai pemungkin seluruh pendekatan ini. Dalam praktik, pandangan kedua lebih masuk akal: begitu Anda ingin merilis berdasarkan audiens, bukan berdasarkan server, Anda membutuhkan flag. Namun flag punya biaya. Setiap flag adalah cabang yang harus dicakup tes, dan tiket pembersihan yang harus ditutup oleh seseorang. Versi panjangnya, kami sudah membahas mekanisme dan utangnya di [apa itu feature flag](/journal/what-is-a-feature-flag). Perlakukan setiap flag sebagai sementara, dengan pemilik dan tanggal penghapusan yang jelas. LaunchDarkly dan Statsig menjual lapisan manajemennya: aturan targeting, audit log, rilis persentase bertahap, dan eksperimen. ## Apa yang membuat rilis progresif, bukan sekadar lambat? Otomatisasi. Rilis yang berhenti selama sepuluh menit sementara manusia memelototi dashboard hanyalah deploy yang lambat. Ia menjadi progressive delivery ketika mesin yang memeriksa metrik dan membuat keputusan. Polanya sama di mana pun: - Tentukan sinyal sebelum rilis: error rate, latensi p95, dan satu metrik bisnis seperti tingkat penyelesaian checkout. - Tentukan ambang batas yang berarti "berhenti", ditulis di konfigurasi, bukan di kepala seseorang. - Biarkan controller mempromosikan, menahan, atau membatalkan rilis berdasarkan sinyal tersebut. Argo Rollouts terintegrasi dengan penyedia metrik sehingga rilis bisa dipromosikan atau dibatalkan secara otomatis tergantung hasil pemeriksaan. Salah satu sumber yang kami tinjau menyatakannya dengan lugas: progressive delivery tanpa rollback otomatis hanyalah deployment yang lambat. Kami setuju. ![Tangan developer di atas keyboard di samping monitor dengan grafik metrik yang buram](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/33c271-i3.webp) ### Metrik apa yang sebaiknya menjadi gerbang rilis? Jaga agar jumlahnya kecil. Tiga atau empat sinyal yang sudah Anda percayai lebih baik daripada dua puluh sinyal yang tidak pernah Anda pasangi alert. Titik awal yang layak: rasio error HTTP 5xx pada canary dibandingkan baseline, latensi p95 canary dibandingkan baseline, saturasi (CPU, memori, kedalaman antrean), dan satu metrik produk. Bandingkan canary dengan baseline pada waktu yang sama, bukan canary dengan "minggu lalu", karena pola traffic terus bergeser. Di sinilah observability berhenti menjadi pelengkap. Jika Anda tidak bisa memecah metrik per versi atau per varian flag, Anda tidak bisa membedakan canary dari baseline, dan seluruh pendekatan ini runtuh. Pengantar kami tentang [apa itu observability](/journal/what-is-observability) membahas cara mencapainya. ### Bagaimana progressive delivery berhubungan dengan trunk-based development? Keduanya saling melengkapi. [Trunk-based development](/journal/what-is-trunk-based-development) menjaga cabang tetap pendek dan menggabungkan perubahan kecil dengan sering. Risikonya, pekerjaan yang belum selesai atau belum diuji masuk ke main lebih sering. Progressive delivery membuat hal itu aman: kode masuk ke trunk, dikirim dalam keadaan tersembunyi di balik flag, lalu dirilis secara bertahap. Batch kecil ditambah paparan bertahap juga membuat debugging lebih murah. Ketika canary gagal, daftar tersangkanya hanya satu perubahan, bukan empat puluh. Siapa pun yang pernah melakukan bisect seminggu commit yang sudah digabung pada pukul 23.00 tahu nilai hal ini. ## Apa langkah awal yang realistis untuk tim 10 sampai 30 engineer? Jangan mulai dengan memasang service mesh. Mulailah dari hal terkecil yang memberi Anda tombol berhenti. - **Minggu 1:** bungkus satu fitur berisiko dengan flag dan rilis lebih dulu ke tim Anda sendiri. - **Minggu 2:** tambahkan dashboard per versi untuk error rate dan latensi. Jika tooling Anda tidak bisa memecah data per versi, perbaiki itu terlebih dahulu. - **Minggu 3 dan seterusnya:** pindahkan satu layanan stateless ke canary controller dengan dua atau tiga langkah dan pembatalan otomatis saat error rate naik. Ukur dalam jam, bukan dalam "rasa aman". Hitung berapa insiden yang berhasil dibatasi pada sebagian kecil pengguna, dan berapa lama rollback memakan waktu. Dua angka itu akan memberi tahu Anda apakah cara ini berhasil untuk tim Anda. ## Di mana rilis progresif biasanya rusak? Tiga tempat, dan tidak satu pun berasal dari controller-nya. **Migrasi database.** Canary berarti dua versi kode mengakses database yang sama pada waktu yang sama. Jika versi N+1 menghapus atau mengganti nama kolom yang masih dibaca versi N, canary akan menjatuhkan baseline. Perbaikan yang membosankan tapi andal adalah expand and contract: tambahkan kolom baru lebih dulu, rilis kode yang menulis ke keduanya, backfill, pindahkan pembacaan, dan baru kemudian hapus kolom lama. **Sticky session dan cache.** Jika pengguna berpindah-pindah antara versi lama dan baru pada setiap request, muncul bug yang tidak bisa direproduksi siapa pun. Kunci pengguna ke satu varian selama rilis berlangsung, lewat cookie, ID akun, atau evaluasi flag. **Metrik yang tertinggal.** Metrik konversi yang diperbarui setiap jam tidak bisa menjadi gerbang untuk langkah canary sepuluh menit. Gunakan sinyal cepat (error, latensi) selama rilis berlangsung, dan tinjau metrik bisnis yang lambat sebelum naik dari 50% ke 100%. ### Bagaimana melacak apa yang sedang aktif di repo? Progressive delivery menyebarkan satu rilis ke banyak file konfigurasi, definisi flag, manifes rollout, dan dashboard. Setelah beberapa bulan, pertanyaan "flag mana yang menjaga jalur billing baru, dan siapa pemiliknya?" berubah menjadi rutinitas yang sama: grep, blame, lalu bertanya ke seseorang. Ini masalah membaca kode, bukan masalah tooling. Mencari di repo berdasarkan kunci flag, lalu menelusuri setiap referensi sampai ke titik panggilannya, adalah cara tercepat untuk menemukan flag yang sudah mati dan rollout yang setengah jadi. Alat yang bisa menjawab "di mana flag ini dievaluasi, dan apa yang terjadi saat flag mati?" langsung dari kode Anda menghemat lebih banyak waktu daripada dashboard tambahan. ## Apa yang akan kami lewati Lewati blue-green untuk semua hal jika tagihan infrastruktur Anda sudah menjadi bahan perdebatan. Lewati canary pada layanan yang hampir tidak punya traffic. Lewati tooling rollout yang tidak bisa di-debug siapa pun di tim pada pukul 3 pagi. Masalah sebenarnya bukan strategi yang Anda pilih. Melainkan jarak antara mengirim kode dan mengetahui apa yang dilakukannya di produksi. Progressive delivery mempersempit jarak itu satu potong traffic per waktu, dan potongan pertama adalah yang paling penting: buat kecil, buat bisa diamati, dan sediakan tombol mati. ## FAQ ### Apa itu progressive delivery dengan sederhana? Ini merilis perangkat lunak dulu ke sebagian kecil pengguna, memeriksa metrik nyata, dan memperluas audiens hanya jika angkanya tetap sehat. Jika tidak, rilis dihentikan atau dikembalikan. ### Apa bedanya progressive delivery dengan continuous delivery? Continuous delivery membuat setiap perubahan siap dirilis. Progressive delivery mengatur bagaimana rilis sampai ke pengguna: berdasarkan persentase traffic, audiens, atau environment, dengan pemeriksaan metrik di antara setiap langkah. ### Apakah canary release sama dengan progressive delivery? Tidak. Canary adalah satu teknik. Progressive delivery adalah praktik yang lebih luas, yang juga mencakup blue-green deployment, feature flag, serta analisis dan rollback otomatis. ### Apakah saya perlu Kubernetes untuk progressive delivery? Tidak. Feature flag bisa dipakai di aplikasi apa pun. Persentase canary yang presisi memang membutuhkan sesuatu yang membagi traffic, seperti service mesh, ingress controller, atau load balancer dengan weighted routing. ### Kapan blue-green lebih baik daripada canary? Ketika rilis sebagian akan membingungkan atau berisiko, misalnya jalur pembayaran yang tidak boleh melayani request dengan dua versi sekaligus. Harganya adalah infrastruktur dua kali lipat selama kedua environment berjalan. ### Metrik apa yang sebaiknya menjadi gerbang rilis progresif? Mulailah dengan rasio error canary dibanding baseline, latensi p95 dan saturasi, ditambah satu metrik produk yang cepat. Bandingkan kedua versi pada waktu yang sama dan jaga agar kumpulannya tetap kecil. ### Bagaimana feature flag berhubungan dengan progressive delivery? Flag bekerja di dalam aplikasi, sehingga Anda bisa merilis berdasarkan audiens, bukan berdasarkan server. Ini kontrol paling granular, tetapi setiap flag membutuhkan pemilik dan tanggal penghapusan.