Strategi pelepasan Canary vs. Biru / Hijau

Pemahaman saya tentang canary release adalah rilis parsial ke subset node produksi dengan sesi melekat yang diaktifkan. Dengan begitu Anda dapat mengontrol dan meminimalkan jumlah pengguna / pelanggan yang terkena dampak jika Anda akhirnya merilis bug yang buruk.

Pemahaman saya tentang rilis biru / hijau adalah bahwa Anda memiliki 2 lingkungan produksi yang dicerminkan ("biru" dan "hijau"), dan Anda mendorong perubahan ke semua node baik biru atau hijau sekaligus, dan kemudian menggunakan keajaiban jaringan untuk mengontrol lingkungan mana pengguna diarahkan melalui DNS.

Jadi, sebelum saya mulai, jika ada yang saya katakan sejauh ini tidak benar, silakan mulai dengan mengoreksi saya!

Dengan asumsi saya kurang lebih di jalurnya, maka beberapa pertanyaan tentang dua strategi:

• Apakah ada skenario di mana kenari lebih disukai daripada biru / hijau, dan sebaliknya?
• Adakah skenario di mana model penerapan dapat mengimplementasikan kedua strategi pada waktu yang sama?

Pelepasan biru-hijau lebih sederhana dan lebih cepat.

Anda dapat melakukan rilis biru-hijau jika Anda telah menguji versi baru di lingkungan pengujian dan sangat yakin bahwa versi baru akan berfungsi dengan benar dalam produksi. Selalu menggunakan pengalih fitur adalah cara yang baik untuk meningkatkan kepercayaan diri Anda pada versi baru, karena versi baru berfungsi persis seperti yang lama hingga seseorang membalik pengalih fitur. Memecah aplikasi Anda menjadi layanan kecil yang dapat dirilis secara independen adalah hal lain, karena lebih sedikit yang harus diuji dan lebih sedikit yang bisa rusak.

Anda perlu melakukan rilis canary jika tidak sepenuhnya yakin bahwa versi baru akan berfungsi dengan benar dalam produksi. Bahkan jika Anda seorang penguji yang teliti, Internet adalah tempat yang besar dan kompleks dan selalu datang dengan tantangan yang tidak terduga. Bahkan jika Anda menggunakan fitur toggles, salah satunya mungkin diterapkan secara tidak benar.

Otomatisasi penerapan membutuhkan usaha, sehingga sebagian besar organisasi akan berencana untuk menggunakan satu strategi atau yang lain setiap saat.

Jadi lakukan penerapan biru-hijau jika Anda berkomitmen pada praktik yang membuat Anda percaya diri dalam melakukannya. Jika tidak, kirimkan kenari.

Esensi biru-hijau diterapkan sekaligus dan esensi penerapan canary diterapkan secara bertahap, jadi mengingat satu kumpulan pengguna, saya tidak dapat memikirkan proses yang akan saya gambarkan sebagai melakukan keduanya pada saat yang sama. Jika Anda memiliki beberapa kumpulan pengguna independen, misalnya menggunakan pusat data regional yang berbeda, Anda dapat melakukan biru-hijau dalam setiap pusat data dan canary di seluruh pusat data. Meskipun jika Anda tidak memerlukan penerapan canary dalam pusat data, Anda mungkin tidak membutuhkannya di seluruh pusat data.

Saya telah menulis esai terperinci tentang topik ini di sini: http://blog.itaysk.com/2017/11/20/deployment-strategies-defined

Menurut pendapat saya, perbedaannya adalah apakah versi 'hijau' yang baru diekspos ke pengguna sebenarnya atau tidak. Jika ya, maka saya akan menyebutnya Canary. Cara umum untuk mengimplementasikan Canary adalah Biru / Hijau biasa dengan penambahan perutean cerdas dari pengguna tertentu ke versi baru. Baca posting untuk perbandingan rinci

Biru hijau:

Kenari:

Meskipun kedua istilah ini terlihat sangat mirip satu sama lain, keduanya memiliki perbedaan yang halus. Yang satu percaya pada rilis fungsionalitas Anda dan yang lainnya percaya pada cara Anda merilis.

Kenari

1. Rilis canary adalah teknik untuk mengurangi risiko memperkenalkan versi perangkat lunak baru dalam produksi dengan meluncurkan perubahan secara perlahan ke sebagian kecil pengguna sebelum meluncurkannya ke seluruh infrastruktur.

2. Ini akan mendapatkan gambaran tentang bagaimana versi baru akan bekerja (terintegrasi dengan aplikasi lain, CPU, memori, penggunaan disk, dll).

Biru hijau:

1. Ini lebih tentang rilis yang dapat diprediksi dengan penerapan zero downtime.
2. Kemunduran mudah jika terjadi kegagalan.
3. Proses penerapan yang sepenuhnya otomatis

Berikut adalah beberapa definisi sebaris -

• Penyebaran Biru-Hijau - Saat menerapkan versi baru aplikasi, lingkungan kedua dibuat. Setelah diuji, lingkungan baru akan mengambil alih dari versi lama. Lingkungan lama kemudian dapat dimatikan.

   

• Pengujian A / B - Dua versi aplikasi berjalan pada waktu yang sama. Sebagian permintaan pergi ke masing-masing. Pengembang kemudian dapat membandingkan versinya.  
• Canary Release - Layanan mikro versi baru dimulai bersama dengan versi lama. Versi baru tersebut kemudian dapat mengambil sebagian dari permintaan dan tim dapat menguji bagaimana versi baru ini berinteraksi dengan sistem secara keseluruhan.

Awal yang baik dari definisi. Saya pikir itu juga membantu dalam membuat keputusan untuk strategi Anda jika Anda membagi definisi "rilis" dalam "menyebarkan" dan "rilis (fungsionalitas)".

Deploy (binari)

Tindakan penerapan biner produk Anda ke sistem (produksi).

Rilis (fungsionalitas)

Tindakan mengelola ketersediaan fungsionalitas untuk (kelompok) pengguna.

Mengapa? Biasanya Anda memiliki (beberapa) dua masalah saat "merilis": 1) Bug / kompatibilitas mundur / dll 2) Memverifikasi validitas / kegunaan fitur baru

Kemudian tanyakan pada diri Anda, sebelum memilih Canary atau Biru / hijau atau strategi mode abu-abu / campuran apa pun: Apa kekhawatiran yang kita miliki saat merilis / menerapkan versi baru? Dan hanya jika Anda mengetahui kekhawatiran Anda, pilih strategi Anda.

Selain itu, dimungkinkan untuk melakukan strategi Deploy / Release yang lebih kompleks. Misalnya, di beberapa cloud / infra, dimungkinkan untuk memiliki beberapa server produksi, dan memuat relai dalam proporsi yang berbeda ke server dan versi produk Anda yang berbeda, dan memantau kesehatan sebelum menskalakan rilis / penerapan ke semua pengguna.

Penandaan fitur

Tindakan "mengonfigurasi" (dingin, atau bahkan panas) fungsi mana yang (tidak) tersedia untuk (grup) pengguna mana

Jika Anda juga melakukan sesuatu seperti "penandaan fitur", Anda dapat menerapkannya terlebih dahulu, mengukur kelayakan rilis Anda dalam kompatibilitas mundur / perspektif bug, dan merilis fungsionalitas baru secara bertahap ke pengguna yang berbeda, atau sebaliknya (memperkecil atau bahkan mengembalikan fungsi dan / atau biner ). Penandaan fitur memungkinkan pemisahan ketersediaan fungsionalitas dari penerapan biner, dan memberikan pengambilan keputusan yang lebih mendetail daripada hanya "terapkan / kembalikan"