Dalam pengembangan aplikasi modern, melakukan deployment secara langsung ke seluruh pengguna memiliki risiko yang cukup besar. Perubahan kode yang terlihat aman saat diuji di development atau staging tetap dapat menimbulkan masalah ketika digunakan pada lingkungan production dengan kondisi traffic dan perilaku pengguna yang sebenarnya.<\/p>\n
Untuk mengurangi risiko tersebut, tim DevOps dan software engineering dapat menggunakan Canary Deployment.<\/em> Strategi ini memungkinkan versi aplikasi yang baru dirilis kepada sebagian kecil pengguna atau traffic terlebih dahulu sebelum diterapkan secara penuh.<\/p>\n Dengan pendekatan tersebut, tim dapat mengamati performa, error, penggunaan resource, dan respons pengguna terhadap versi baru. Jika tidak ditemukan masalah berarti, traffic dapat ditingkatkan secara bertahap hingga seluruh pengguna menggunakan versi terbaru.<\/p>\n Google Cloud mendefinisikan canary deployment sebagai progressive rollout yang membagi traffic antara versi yang sudah berjalan dan versi baru, kemudian secara bertahap meningkatkan porsi traffic ke versi baru.<\/p>\n Tentu. Berikut versi yang lebih natural, berbentuk paragraf, dan tetap SEO-friendly tanpa pengulangan keyword berlebihan:<\/p>\n Canary Deployment adalah strategi deployment yang dilakukan dengan merilis versi baru aplikasi secara bertahap kepada sebagian kecil pengguna atau traffic sebelum diterapkan sepenuhnya ke seluruh pengguna. Pendekatan ini memungkinkan tim pengembang menguji perilaku aplikasi dalam lingkungan production secara lebih terkendali, sehingga potensi masalah dapat diketahui sebelum memberikan dampak yang lebih luas.<\/p>\n Dalam penerapannya, versi lama dan versi baru biasanya berjalan secara bersamaan. Sebagian kecil traffic diarahkan ke versi terbaru sebagai canary<\/em>, sementara sebagian besar pengguna masih menggunakan versi lama yang telah terbukti stabil. Sebagai contoh, ketika sebuah aplikasi memiliki 100% traffic production, tim dapat mengarahkan sekitar 95% traffic ke versi lama dan 5% ke versi baru. Selama tahap tersebut, berbagai indikator seperti error rate, latency, penggunaan resource, dan performa aplikasi dapat dipantau untuk mengetahui apakah release baru berjalan dengan baik.<\/p>\n Jika hasil pemantauan menunjukkan bahwa versi terbaru tetap stabil, distribusi traffic dapat ditingkatkan secara bertahap, misalnya menjadi 25%, 50%, 75%, hingga akhirnya seluruh traffic menggunakan versi baru. Tahapan tersebut tidak harus menggunakan persentase yang sama pada setiap implementasi karena dapat disesuaikan dengan tingkat risiko perubahan, karakteristik aplikasi, jumlah traffic, serta kemampuan monitoring yang tersedia.<\/p>\n Pendekatan bertahap tersebut menjadi salah satu keunggulan utama Canary Deployment karena versi baru tidak langsung digunakan oleh seluruh pengguna. Jika ditemukan bug, peningkatan error, penurunan performa, atau masalah lainnya, tim dapat menghentikan proses rollout dan mengembalikan traffic ke versi sebelumnya. Dengan demikian, dampak kegagalan deployment dapat dibatasi sekaligus memberikan kesempatan bagi tim untuk melakukan evaluasi sebelum melanjutkan penerapan ke skala yang lebih besar.<\/p>\n Istilah canary<\/em> berasal dari praktik lama di pertambangan batu bara yang menggunakan burung kenari sebagai indikator adanya gas berbahaya. Dalam konteks software deployment, istilah tersebut digunakan sebagai metafora. Versi aplikasi yang baru dirilis kepada sebagian kecil traffic berfungsi sebagai semacam indikator awal.<\/p>\n Jika versi baru mengalami masalah, dampaknya dapat dibatasi pada sebagian kecil pengguna. Jika hasil pengamatan menunjukkan bahwa versi tersebut stabil, deployment dapat dilanjutkan kepada lebih banyak pengguna. Namun, Canary Deployment bukan berarti versi baru otomatis aman hanya karena tidak menimbulkan error pada kelompok pengguna pertama. Monitoring, observability, testing, dan kriteria keberhasilan tetap diperlukan untuk mengambil keputusan apakah rollout harus dilanjutkan, dihentikan, atau di-rollback<\/em>.<\/p>\n Secara umum, Canary Deployment bekerja melalui beberapa tahap.<\/p>\n 1. Menyiapkan Versi Baru<\/span><\/p>\n Tim developer terlebih dahulu membuat perubahan aplikasi, kemudian menjalankan proses build, testing, dan deployment sesuai pipeline CI\/CD. Versi baru tidak langsung diberikan kepada seluruh pengguna.<\/p>\n 2. Menjalankan Versi Lama dan Baru<\/span><\/p>\n Versi lama tetap berjalan sebagai versi stabil, sedangkan versi baru dijalankan sebagai target canary. Keduanya dapat berjalan secara bersamaan sehingga traffic dapat dibagi di antara kedua versi.<\/p>\n 3. Mengarahkan Sebagian Traffic ke Versi Baru<\/span><\/p>\n Load balancer, ingress, service mesh, gateway, platform cloud, atau mekanisme traffic management lainnya dapat digunakan untuk menentukan distribusi traffic. Misalnya:<\/p>\n Pada tahap ini, 10% traffic menjadi kelompok pengujian terhadap versi baru.<\/p>\n 4. Melakukan Monitoring<\/span><\/p>\n Tim kemudian mengamati berbagai indikator, seperti:<\/p>\n Monitoring penting karena keberhasilan deployment tidak hanya ditentukan oleh apakah aplikasi dapat dijalankan. Sebuah versi baru mungkin terlihat sehat dari sisi server, tetapi ternyata menyebabkan transaksi gagal atau menurunkan conversion rate.<\/p>\n 5. Mengevaluasi Hasil Canary<\/span><\/p>\n Setelah versi baru berjalan selama periode tertentu atau mencapai jumlah request tertentu, hasil monitoring dibandingkan dengan baseline versi lama. Jika metrik berada dalam batas yang telah ditentukan, rollout dapat dilanjutkan. Jika terjadi peningkatan error atau masalah serius, rollout dapat dihentikan dan traffic dikembalikan ke versi lama.<\/p>\n 6. Meningkatkan Traffic Secara Bertahap<\/span><\/p>\n Jika canary dianggap berhasil, traffic ke versi baru dapat dinaikkan. 7. Menjadikan Versi Baru sebagai Versi Utama<\/span><\/p>\n Setelah seluruh traffic berpindah ke versi baru dan tidak ditemukan masalah kritis, versi tersebut menjadi deployment utama. Versi lama kemudian dapat dihentikan atau dipertahankan sementara sebagai bagian dari strategi rollback.<\/p>\n Misalnya sebuah website e-commerce memiliki 1 juta request per hari. Tim ingin merilis versi checkout baru. Karena checkout merupakan fitur kritis, deployment langsung kepada seluruh pengguna memiliki risiko tinggi. Tim kemudian menerapkan Canary Deployment. Tahap pertama:<\/p>\n Setelah beberapa waktu, tim menemukan bahwa error rate versi baru masih berada dalam batas normal. Traffic kemudian dinaikkan:<\/p>\n Misalnya pada tahap 50% ditemukan peningkatan error checkout yang signifikan. Tim dapat menghentikan rollout dan mengembalikan traffic ke versi lama. Dengan demikian, masalah tidak langsung berdampak pada seluruh pengguna.<\/p>\n Canary Deployment dapat diterapkan dengan beberapa pendekatan.<\/p>\n 1. Traffic-Based Canary<\/span><\/p>\n Traffic dibagi berdasarkan persentase antara versi lama dan versi baru. Contohnya:<\/p>\n Kemudian traffic versi baru dinaikkan secara bertahap. Pendekatan ini umum digunakan pada platform yang menyediakan traffic splitting.<\/p>\n 2. User-Based Canary<\/span><\/p>\n Tidak semua pengguna mendapatkan versi baru secara acak. Sistem dapat menentukan kelompok pengguna tertentu sebagai canary. Misalnya:<\/p>\n Pendekatan ini berguna ketika perusahaan ingin mengontrol siapa yang mendapatkan fitur baru.<\/p>\n 3. Region-Based Canary<\/span><\/p>\n Versi baru terlebih dahulu diterapkan pada region atau lokasi tertentu. Misalnya:<\/p>\n Jika hasil deployment di Region A baik, deployment dapat diperluas ke region lainnya. Pendekatan seperti ini dapat berguna bagi aplikasi global yang memiliki beberapa region deployment.<\/p>\n 4. Percentage-Based Canary<\/span><\/p>\n Traffic dinaikkan menggunakan persentase tertentu. Canary Deployment bukan hanya tentang membagi traffic. Agar strategi ini berjalan dengan baik, terdapat beberapa komponen penting.<\/p>\n 1. Load Balancer atau Traffic Router<\/span><\/p>\n Komponen ini menentukan ke mana request pengguna diarahkan. Traffic router dapat mengatur distribusi request antara versi lama dan versi baru berdasarkan persentase, region, user group, header, cookie, atau aturan lainnya.<\/p>\n 2. Monitoring dan Observability<\/span><\/p>\n Tim harus mampu mengetahui apakah versi baru bekerja dengan baik. Observability biasanya mencakup:<\/p>\n Tanpa observability yang baik, Canary Deployment akan kehilangan salah satu manfaat utamanya karena tim tidak memiliki informasi yang cukup untuk menentukan apakah rollout aman.<\/p>\n 3. Automated Testing<\/span><\/p>\n Testing tetap penting sebelum dan selama deployment. Canary bukan pengganti automated testing. Canary lebih tepat dipandang sebagai lapisan validasi tambahan pada kondisi production.<\/p>\n 4. Rollback Mechanism<\/span><\/p>\n Deployment harus memiliki mekanisme untuk menghentikan rollout dan kembali ke versi sebelumnya jika terjadi masalah. Rollback menjadi semakin penting ketika versi baru berkaitan dengan komponen kritis seperti authentication, payment, database, atau API utama.<\/p>\n 5. Deployment Pipeline<\/span><\/p>\n Canary biasanya menjadi bagian dari pipeline CI\/CD. Pipeline dapat mengatur proses seperti:<\/p>\n Dengan pipeline otomatis, proses deployment dapat dilakukan secara konsisten dan mengurangi ketergantungan terhadap tindakan manual.<\/p>\n Keberhasilan Canary Deployment sangat bergantung pada metrik yang digunakan.<\/p>\n 1. Error Rate<\/span><\/p>\n Error rate merupakan salah satu indikator paling penting. Jika versi baru memiliki error rate jauh lebih tinggi dibandingkan versi lama, rollout sebaiknya dihentikan dan dilakukan investigasi.<\/p>\n 2. Latency<\/span><\/p>\n Perubahan kode dapat menyebabkan aplikasi menjadi lebih lambat meskipun tidak menghasilkan error. Karena itu, latency perlu dibandingkan antara versi lama dan versi baru.<\/p>\n 3. Resource Usage<\/span><\/p>\n Perhatikan penggunaan:<\/p>\n Versi baru mungkin membutuhkan resource jauh lebih besar daripada versi sebelumnya.<\/p>\n 4. Availability<\/span><\/p>\n Tim perlu memastikan bahwa deployment baru tidak menyebabkan peningkatan downtime atau kegagalan request.<\/p>\n 5. Business Metrics<\/span><\/p>\n Untuk aplikasi yang berorientasi bisnis, metrik teknis saja tidak selalu cukup. Contohnya:<\/p>\n Sebuah deployment dapat memiliki CPU dan latency yang normal, tetapi tetap bermasalah apabila menyebabkan transaksi gagal.<\/p>\n Canary Deployment memiliki beberapa kelebihan dibandingkan deployment langsung.<\/p>\n Meskipun memberikan banyak manfaat, Canary Deployment juga memiliki beberapa tantangan.<\/p>\n Canary Deployment dan Rolling Deployment sama-sama dapat digunakan untuk mengurangi risiko deployment, tetapi mekanismenya berbeda.<\/p>\n Dalam praktiknya, kedua strategi juga dapat dikombinasikan tergantung arsitektur dan tooling yang digunakan.<\/p>\n Canary dan Blue-Green Deployment sering dibandingkan karena keduanya dapat menjalankan versi lama dan versi baru secara bersamaan.<\/p>\n AWS juga menjelaskan Canary Deployment sebagai pendekatan blue\/green yang lebih berhati-hati karena traffic dipindahkan secara bertahap, dimulai dari persentase kecil.<\/p>\n Canary Deployment juga berbeda dengan A\/B testing meskipun keduanya sama-sama dapat melibatkan pembagian pengguna.<\/p>\n Dengan demikian, Canary Deployment bukan sekadar metode eksperimen terhadap pengguna. Tujuan utamanya adalah melakukan release secara lebih aman dan bertahap.<\/p>\n Tidak<\/em>.<\/strong> Canary Deployment tidak hanya dapat diterapkan pada Kubernetes. Strategi ini pada dasarnya dapat digunakan pada berbagai arsitektur dan platform selama tersedia mekanisme untuk menjalankan versi aplikasi yang berbeda secara bersamaan serta mengatur distribusi traffic atau kelompok pengguna. Karena itu, penerapannya dapat disesuaikan dengan infrastruktur dan kebutuhan masing-masing aplikasi.<\/p>\n Kubernetes memang menjadi salah satu platform yang banyak digunakan untuk menerapkan pola deployment ini karena memungkinkan tim menjalankan beberapa versi aplikasi dan mengatur bagaimana request diarahkan ke masing-masing versi. Namun, penerapannya tidak harus selalu menggunakan Kubernetes. Pendekatan serupa dapat diterapkan dengan memanfaatkan load balancer, service mesh, API gateway, container platform, maupun layanan serverless yang menyediakan kemampuan pengaturan traffic.<\/p>\n Pada lingkungan cloud, misalnya, Canary Deployment dapat diterapkan menggunakan layanan seperti Google Kubernetes Engine (GKE) dan Cloud Run. Pada Cloud Run, traffic dapat didistribusikan di antara revision aplikasi yang berbeda berdasarkan persentase yang telah ditentukan. Dengan mekanisme tersebut, tim dapat memberikan sebagian traffic kepada revision terbaru terlebih dahulu, melakukan pemantauan, kemudian meningkatkan distribusinya apabila hasil evaluasi menunjukkan bahwa aplikasi tetap berjalan dengan baik.<\/p>\n Dengan demikian, penggunaan Canary Deployment lebih bergantung pada kemampuan sistem dalam mengelola versi aplikasi, traffic routing, monitoring, dan rollback daripada pada platform tertentu. Kubernetes merupakan salah satu pilihan populer, tetapi bukan satu-satunya teknologi yang dapat digunakan untuk menerapkan strategi deployment secara bertahap.<\/p>\n Dalam Kubernetes, Canary Deployment dapat dilakukan dengan menjalankan beberapa Deployment yang mewakili versi aplikasi berbeda. Contohnya:<\/p>\n Service atau mekanisme traffic management kemudian digunakan untuk menentukan request yang masuk ke masing-masing versi. Pendekatan yang lebih sederhana dapat menggunakan jumlah replica sebagai representasi proporsi traffic, tetapi pendekatan tersebut tidak selalu menghasilkan distribusi traffic yang presisi. Untuk kebutuhan routing yang lebih kompleks, tim dapat menggunakan ingress, gateway, atau service mesh.<\/p>\n Karena itu, implementasi Canary Deployment pada Kubernetes perlu disesuaikan dengan kebutuhan routing dan tingkat kontrol traffic yang diperlukan.<\/p>\n Canary Deployment sangat cocok dikombinasikan dengan pipeline CI\/CD. Contoh alurnya:<\/p>\n Dalam implementasi yang lebih matang, keputusan untuk melanjutkan rollout dapat dibuat otomatis berdasarkan hasil monitoring. Google Cloud Cloud Deploy juga menyediakan tahapan canary dan mendukung analisis deployment untuk membantu menentukan kapan rollout dapat dilanjutkan.<\/p>\n Canary Deployment sebaiknya dipertimbangkan ketika aplikasi memiliki traffic yang cukup tinggi atau perubahan yang dilakukan berpotensi memberikan dampak besar kepada pengguna. Strategi ini sangat berguna untuk aplikasi yang harus tetap tersedia selama proses deployment, terutama ketika downtime, bug, atau penurunan performa dapat menyebabkan kerugian bagi bisnis maupun mengganggu layanan.<\/p>\n Penerapan pendekatan ini juga lebih tepat ketika infrastruktur sudah mendukung pengaturan distribusi traffic antara versi aplikasi yang berbeda. Selain itu, tim sebaiknya memiliki sistem monitoring dan observability yang memadai untuk memantau error rate, latency, penggunaan resource, serta indikator lain yang relevan. Automated testing juga penting agar masalah dapat ditemukan sebelum dan selama proses release.<\/p>\n Canary Deployment semakin bermanfaat ketika organisasi menerapkan deployment secara rutin dan membutuhkan proses progressive delivery<\/em> yang lebih terkontrol. Perubahan yang memiliki tingkat risiko tinggi, seperti pembaruan fitur utama, API, authentication, sistem pembayaran, atau komponen backend yang penting, dapat dirilis secara bertahap untuk membatasi dampak apabila terjadi masalah. Agar strategi ini efektif, mekanisme rollback juga harus tersedia dan dapat dijalankan dengan cepat ketika hasil monitoring menunjukkan bahwa versi baru tidak memenuhi kriteria yang telah ditentukan.<\/p>\n Agar Canary Deployment berjalan efektif, beberapa praktik berikut dapat diterapkan.<\/p>\n Tentukan Success Criteria<\/span><\/p>\n Sebelum deployment dimulai, tentukan terlebih dahulu kondisi yang dianggap berhasil. Contohnya:<\/p>\n Dengan demikian, keputusan rollout tidak hanya berdasarkan intuisi.<\/p>\n Mulai dengan Traffic Kecil<\/span><\/p>\n Untuk perubahan yang memiliki risiko tinggi, mulai dengan porsi traffic kecil. Misalnya 1%, 5%, atau 10%, kemudian tingkatkan setelah hasil monitoring menunjukkan kondisi yang sehat.<\/p>\n Gunakan Automated Monitoring<\/span><\/p>\n Monitoring manual memiliki keterbatasan, terutama ketika deployment dilakukan pada skala besar. Gunakan alert dan automated analysis jika memungkinkan.<\/p>\n Siapkan Rollback Sebelum Deployment<\/span><\/p>\n Jangan menunggu masalah terjadi baru memikirkan rollback. Prosedur rollback sebaiknya sudah diuji sebelum deployment dilakukan.<\/p>\n Pastikan Kompatibilitas Antarversi<\/span><\/p>\n Ketika versi lama dan baru berjalan bersamaan, keduanya mungkin berinteraksi dengan database atau service yang sama. Perubahan API dan database sebaiknya dirancang agar kedua versi tetap dapat beroperasi selama masa transisi.<\/p>\n Pantau Technical dan Business Metrics<\/span><\/p>\n Jangan hanya memantau CPU dan error rate. Untuk aplikasi bisnis, pantau juga metrik yang berkaitan langsung dengan tujuan aplikasi.<\/p>\n Gunakan Progressive Rollout<\/span><\/p>\n Tidak semua deployment harus menggunakan tahapan yang sama. Tim dapat menggunakan pola: Tidak.<\/strong> Canary Deployment dapat membantu mengurangi risiko dan membatasi dampak ketika terjadi masalah pada versi aplikasi yang baru dirilis, tetapi strategi ini tidak menjamin bahwa sebuah deployment akan sepenuhnya bebas dari kesalahan. Versi baru tetap dapat mengalami bug atau masalah performa, terutama jika kondisi yang menyebabkan masalah belum muncul selama tahap pengujian awal.<\/p>\n Efektivitas pendekatan ini juga sangat bergantung pada bagaimana proses canary dirancang dan dipantau. Risiko dapat tetap muncul apabila kelompok pengguna yang menerima versi baru tidak cukup mewakili keseluruhan pengguna, jumlah traffic yang diarahkan ke versi tersebut terlalu kecil, atau waktu observasi terlalu singkat. Masalah tertentu juga mungkin hanya muncul pada kondisi traffic tertentu, fitur tertentu, atau segmen pengguna tertentu sehingga tidak langsung terlihat selama tahap awal rollout.<\/p>\n Selain itu, sistem monitoring yang kurang lengkap dapat menyebabkan masalah tidak terdeteksi meskipun sebenarnya sudah terjadi. Perubahan pada database juga perlu diperhatikan karena versi lama dan versi baru dapat berjalan secara bersamaan selama proses deployment. Jika struktur database atau API tidak kompatibel dengan kedua versi tersebut, proses rollout dapat menimbulkan masalah meskipun aplikasi secara umum terlihat berjalan normal.<\/p>\n Oleh karena itu, Canary Deployment sebaiknya dipahami sebagai mekanisme untuk mengurangi risiko deployment, bukan sebagai jaminan bahwa sebuah release pasti aman. Hasil yang optimal tetap membutuhkan automated testing, monitoring yang tepat, kriteria keberhasilan yang jelas, observability yang baik, serta mekanisme rollback yang dapat digunakan dengan cepat apabila ditemukan masalah.<\/p>\n Canary Deployment adalah strategi deployment yang merilis versi baru aplikasi secara bertahap kepada sebagian kecil pengguna atau traffic sebelum memperluasnya kepada seluruh pengguna.<\/strong> Pendekatan ini memungkinkan tim melakukan validasi pada kondisi production nyata dengan dampak yang lebih terbatas. Jika versi baru menunjukkan performa yang baik, traffic dapat ditingkatkan secara bertahap hingga mencapai 100%. Sebaliknya, jika ditemukan masalah, rollout dapat dihentikan atau dilakukan rollback sebelum berdampak pada seluruh pengguna.<\/p>\n Strategi ini sangat relevan dalam praktik DevOps, CI\/CD, cloud computing, microservices, dan progressive delivery. Namun, keberhasilannya tetap bergantung pada monitoring, observability, automated testing, traffic management, serta prosedur rollback yang baik. Canary Deployment juga bukan berarti menghilangkan seluruh risiko, melainkan membantu mengurangi dampak kegagalan dengan menerapkan proses rilis secara lebih terkontrol.<\/p>\n Bagi Anda yang ingin memperdalam pengetahuan mengenai deployment, DevOps, cloud computing, server, hosting, dan berbagai teknologi pengembangan website, Blog Hosteko<\/strong><\/em><\/a> dapat menjadi salah satu referensi untuk mempelajari berbagai topik teknologi secara lebih luas. Dengan menerapkan strategi deployment yang sesuai dan didukung infrastruktur yang tepat, proses pengembangan serta pengelolaan aplikasi dapat dilakukan secara lebih aman, terukur, dan efisien.<\/p>\n\n\nApa Itu Canary Deployment?<\/h2>\n
Mengapa Disebut Canary Deployment?<\/h2>\n
Bagaimana Cara Kerja Canary Deployment?<\/h2>\n
\n\n
\n \nVersi<\/th>\n Traffic<\/th>\n<\/tr>\n<\/thead>\n \n Versi lama<\/td>\n 90%<\/td>\n<\/tr>\n \n Versi baru<\/td>\n 10%<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n
\nContohnya: 5% \u2192 10% \u2192 25% \u2192 50% \u2192 75% \u2192 100%<\/em>
\n<\/strong>Tidak ada persentase yang wajib digunakan untuk semua sistem. Tahapan tersebut harus disesuaikan dengan karakteristik aplikasi, traffic, risiko perubahan, dan kemampuan monitoring.<\/p>\nContoh Sederhana Canary Deployment<\/h2>\n
\n
\n\n
\n \nTahap<\/th>\n Versi Lama<\/th>\n Versi Baru<\/th>\n Evaluasi<\/th>\n<\/tr>\n<\/thead>\n \n 1<\/td>\n 95%<\/td>\n 5%<\/td>\n Monitoring awal<\/td>\n<\/tr>\n \n 2<\/td>\n 90%<\/td>\n 10%<\/td>\n Cek error dan latency<\/td>\n<\/tr>\n \n 3<\/td>\n 75%<\/td>\n 25%<\/td>\n Analisis performa<\/td>\n<\/tr>\n \n 4<\/td>\n 50%<\/td>\n 50%<\/td>\n Validasi lebih luas<\/td>\n<\/tr>\n \n 5<\/td>\n 25%<\/td>\n 75%<\/td>\n Final monitoring<\/td>\n<\/tr>\n \n 6<\/td>\n 0%<\/td>\n 100%<\/td>\n Rollout selesai<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Jenis Canary Deployment<\/h2>\n
Versi lama: 90%\r\nVersi baru: 10%\r\n<\/code><\/pre>\n\n
Region A \u2192 Versi baru\r\nRegion B \u2192 Versi lama\r\nRegion C \u2192 Versi lama\r\n<\/code><\/pre>\n
\nContohnya:5% \u2192 10% \u2192 25% \u2192 50% \u2192 100%
\n<\/code>
\nPendekatan ini merupakan salah satu pola yang paling mudah dipahami karena risiko dapat diperluas secara bertahap.<\/p>\nKomponen Penting dalam Canary Deployment<\/h2>\n
\n
Build\r\n \u2193\r\nAutomated Test\r\n \u2193\r\nDeploy Canary\r\n \u2193\r\nMonitor\r\n \u2193\r\nEvaluate\r\n \u2193\r\nPromote \/ Rollback\r\n \u2193\r\nFull Deployment\r\n<\/code><\/pre>\nApa Saja yang Harus Dimonitor?<\/h2>\n
\n
\n
Kelebihan Canary Deployment<\/h2>\n
\n
\n<\/strong>Perubahan tidak langsung diberikan kepada seluruh pengguna. Jika terjadi bug, jumlah pengguna yang terkena dampak dapat dibatasi.<\/li>\n<\/ul>\n\n
\n<\/strong>Canary memungkinkan tim mengamati perilaku aplikasi dalam kondisi production nyata. Hal ini penting karena traffic dan pola penggunaan production sering kali berbeda dengan staging.<\/li>\n<\/ul>\n\n
\n<\/strong>Jika versi baru memiliki masalah, perbandingan antara versi lama dan versi baru dapat membantu tim menemukan perubahan yang menyebabkan masalah.<\/li>\n<\/ul>\n\n
\nTim tidak harus menyelesaikan deployment hingga 100%. Jika hasil monitoring tidak memenuhi kriteria, rollout dapat dihentikan sebelum seluruh pengguna berpindah ke versi baru.<\/li>\n<\/ul>\n\n
\nCanary sangat berguna untuk perubahan yang memiliki dampak besar terhadap pengguna atau sistem. Contohnya:<\/li>\n<\/ul>\n\n
\n
\n
\n<\/strong>Canary dapat diintegrasikan dengan CI\/CD dan automated verification sehingga keputusan rollout dapat dibuat berdasarkan metrik dan aturan yang telah ditentukan. Google Cloud, misalnya, mendukung deployment analysis pada fase canary menggunakan metrik observability untuk membantu menentukan apakah rollout dapat dilanjutkan.<\/li>\n<\/ul>\nKekurangan Canary Deployment<\/h2>\n
\n
\n<\/strong>Sistem harus mampu menjalankan versi lama dan versi baru secara bersamaan serta mengatur traffic di antara keduanya.<\/li>\n<\/ul>\n\n
\n<\/strong>Tanpa monitoring yang memadai, tim akan kesulitan menentukan apakah deployment baru berhasil.<\/li>\n<\/ul>\n\n
\n<\/strong>Pengaturan traffic splitting dapat membutuhkan load balancer, ingress, service mesh, gateway, atau fitur cloud tertentu.<\/li>\n<\/ul>\n\n
\n<\/strong>Rollback aplikasi relatif mudah jika perubahan hanya berkaitan dengan application code. Namun, rollback dapat menjadi lebih kompleks jika deployment juga mengubah database schema atau data. Karena itu, perubahan database perlu dirancang agar kompatibel selama periode ketika versi lama dan baru masih berjalan bersamaan.<\/li>\n<\/ul>\n\n
\n<\/strong>Tim perlu menentukan:<\/li>\n<\/ul>\n\n
\n
Perbedaan Canary Deployment dan Rolling Deployment<\/h2>\n
\n\n
\n \nAspek<\/th>\n Canary Deployment<\/th>\n Rolling Deployment<\/th>\n<\/tr>\n<\/thead>\n \n Prinsip<\/td>\n Merilis versi baru kepada sebagian traffic\/pengguna terlebih dahulu<\/td>\n Mengganti instance\/pod lama secara bertahap<\/td>\n<\/tr>\n \n Fokus<\/td>\n Exposure terhadap pengguna<\/td>\n Penggantian instance<\/td>\n<\/tr>\n \n Traffic splitting<\/td>\n Umumnya diperlukan<\/td>\n Tidak selalu diperlukan<\/td>\n<\/tr>\n \n Versi lama & baru<\/td>\n Dapat menerima traffic secara bersamaan<\/td>\n Dapat berjalan bersamaan selama proses rollout<\/td>\n<\/tr>\n \n Validasi<\/td>\n Dapat dilakukan berdasarkan traffic canary<\/td>\n Biasanya berdasarkan kesehatan instance<\/td>\n<\/tr>\n \n Rollout<\/td>\n Bertahap berdasarkan traffic atau kelompok pengguna<\/td>\n Bertahap berdasarkan instance\/replica<\/td>\n<\/tr>\n \n Kompleksitas<\/td>\n Relatif tinggi<\/td>\n Umumnya lebih sederhana<\/td>\n<\/tr>\n \n Cocok untuk<\/td>\n Perubahan yang membutuhkan validasi production bertahap<\/td>\n Deployment rutin dengan banyak instance<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Canary Deployment vs Blue-Green Deployment<\/h2>\n
\n\n
\n \nAspek<\/th>\n Canary Deployment<\/th>\n Blue-Green Deployment<\/th>\n<\/tr>\n<\/thead>\n \n Traffic awal<\/td>\n Sebagian traffic ke versi baru<\/td>\n Umumnya traffic diarahkan ke satu environment<\/td>\n<\/tr>\n \n Rollout<\/td>\n Bertahap<\/td>\n Biasanya perpindahan lebih cepat<\/td>\n<\/tr>\n \n Validasi<\/td>\n Dilakukan secara bertahap dengan traffic nyata<\/td>\n Dapat divalidasi sebelum switch penuh<\/td>\n<\/tr>\n \n Risiko<\/td>\n Dampak awal lebih terbatas<\/td>\n Switch penuh dapat berdampak lebih luas jika gagal<\/td>\n<\/tr>\n \n Infrastruktur<\/td>\n Dapat membutuhkan pengaturan traffic splitting<\/td>\n Membutuhkan dua environment yang relatif terpisah<\/td>\n<\/tr>\n \n Rollback<\/td>\n Dapat dilakukan dengan mengurangi\/menghentikan traffic baru<\/td>\n Dapat mengalihkan traffic kembali ke environment sebelumnya<\/td>\n<\/tr>\n \n Cocok untuk<\/td>\n Progressive delivery<\/td>\n Pergantian environment secara cepat<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Canary Deployment vs A\/B Testing<\/h2>\n
\n\n
\n \nAspek<\/th>\n Canary Deployment<\/th>\n A\/B Testing<\/th>\n<\/tr>\n<\/thead>\n \n Tujuan utama<\/td>\n Mengurangi risiko deployment<\/td>\n Membandingkan variasi untuk tujuan eksperimen<\/td>\n<\/tr>\n \n Fokus<\/td>\n Stabilitas dan keamanan release<\/td>\n Perilaku pengguna dan hasil eksperimen<\/td>\n<\/tr>\n \n Durasi<\/td>\n Biasanya selama proses rollout<\/td>\n Dapat berlangsung lebih lama<\/td>\n<\/tr>\n \n Keputusan<\/td>\n Lanjut, hentikan, atau rollback deployment<\/td>\n Pilih variasi berdasarkan hasil eksperimen<\/td>\n<\/tr>\n \n Metrik<\/td>\n Error, latency, availability, resource, business metrics<\/td>\n Conversion, engagement, CTR, dan metrik eksperimen<\/td>\n<\/tr>\n \n Output<\/td>\n Versi baru menjadi production<\/td>\n Variasi terbaik dipilih berdasarkan eksperimen<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Apakah Canary Deployment Hanya untuk Kubernetes?<\/h2>\n
Canary Deployment pada Kubernetes<\/h2>\n
Service\r\n |\r\n +---------+---------+\r\n | |\r\n Version 1 Version 2\r\n Stable Canary\r\n 90% 10%\r\n<\/code><\/pre>\nCanary Deployment dalam CI\/CD<\/h2>\n
Developer\r\n \u2193\r\nGit Repository\r\n \u2193\r\nCI Pipeline\r\n \u2193\r\nBuild & Automated Test\r\n \u2193\r\nDeploy Version Baru\r\n \u2193\r\nCanary 5%\r\n \u2193\r\nAutomated Monitoring\r\n \u2193\r\nApakah memenuhi threshold?\r\n \u251c\u2500\u2500 Tidak \u2192 Rollback\r\n \u2514\u2500\u2500 Ya\r\n \u2193\r\n Canary 25%\r\n \u2193\r\n Monitoring\r\n \u2193\r\n Canary 50%\r\n \u2193\r\n Monitoring\r\n \u2193\r\n 100% Production\r\n<\/code><\/pre>\nKapan Sebaiknya Menggunakan Canary Deployment?<\/h2>\n
Best Practice Canary Deployment<\/h2>\n
\n
1% \u2192 5% \u2192 10% \u2192 25% \u2192 50% \u2192 100%
\n<\/code>, untuk perubahan berisiko tinggi, atau tahapan yang lebih agresif untuk perubahan berisiko rendah.<\/p>\nApakah Canary Deployment Selalu Menghilangkan Risiko?<\/h2>\n
Kesimpulan<\/h2>\n