Pendahuluan

Pengenalan awal mengenai Release Strategy

Strategi Release/Deployment merupakan cara untuk mengakomodasi kebutuhan Release/Deployment sesuai dengan kebutuhannya.

Dan terlebih penting untuk menghindari atau mengurangi : RISIKO

misalnya :

  • Risiko deployment yang membuat sistem yang ada di production sekarang tidak berjalan.
  • Risiko finansial karena sistem yang tidak berjalan atau mengalami error.
  • Risiko reputasi dari customer terhadap sistem di production yang tidak berjalan atau mengalami error.
  • Risiko bahwa sistemnya tidak bisa dikembalikan ke state sebelumnya. Jadinya sistemnya ngegantung dan tidak bisa diapa-apakan.
  • dll.

Canary Deployment


Canary Deployment ?

Burung Kenari ?

Yaa, betul sekali.

Istilah ini mengacu ke burung Kenari ..

Di dunia release, istilah ini dikaitkan dengan sejarah mengenai burung Kenari yang dipakai sebagai pendeteksi sebuah anomali.

Lho..lho.. Ada apa dengan burung Kenari ?


Sejarah


Istilah Miner’s Canary muncul di waktu tahun 1900.

Ketika para penambang batu bara di Inggris mulai menggunakan burung Kenari dalam mendeteksi adanya kebocoran gas seperti Karbon Monoksida, gas Metana, dll di wilayah tambang.

Burung Kenari yang mempunyai tingkat metabolisme pertukaran udara dengan darah yang lebih cepat dibandingkan manusia, menjadikannya sebagai indikator cepat ketika terjadi kebocoran gas di daerah tambang.

Hal ini bisa menjadi alarm bagi para penambang sebelum melakukan dan melanjutkan aktifitasnya.

Fitur dari burung Kenari yang berfungsi sebagai alarm atau pendeteksi dini ini, dicoba di adaptasi di dunia IT.


Di dunia IT


Canary Deployment dalam hal ini mirip dengan kasus penambang di Inggris diatas, yaitu :


  • Strategi Release yang bisa digunakan sebagai pendeteksi dini kalau ternyata ada yang salah dari deploymentnya.
  • Strategi Release yang bisa digunakan untuk mendapatkan feedback secara cepat untuk fitur yang direlease.

Dengan Canary Deployment ini,maka diharapkan Risiko yang lebih besar yang mungkin dihadapi ketika kita melakukan release secara besar dan keseluruhan, bisa dihindari.

Kalau boleh dibilang, Canary Deployment ini adalah Release dengan konsep Test the water dahulu.

Jadi kita melakukan release dengan harapan bisa mendapatkan Real hasil deployment dan feedback, tapi hanya untuk sebagian kecil pengguna atau sebagian kecil server saja, sehingga dengan mudah ditentukan aksi selanjutnya.

Apakah :

  • Releasenya di rollback, karena setelah dicoba oleh sebagian kecil pengguna, ternyata tidak memuaskan dan tidak sesuai dengan ekspektasi.
  • Releasenya di rollback, karena terjadi kesalahan teknis untuk sebagian kecil server dimana fitur ini direlease.
  • Releasenya dilanjutkan karena setelah beberapa waktu berhasil di uji coba dan tidak mendapatkan masalah berarti dan feedback dari pengguna juga bagus.

Dengan demikian, secara implisit Canary Deployment ini dilakukan dengan cara bertahap dan cuma sebagian server saja pada satu waktu.


Caranya bagaimana ?


Canary Deployment ini dilakukan dengan cara :

  • melakukan deployment terhadap sebagian server atau sebagian pengguna tertentu.
  • sehingga di production, pada awal deployment, maka akan ada 2 versi, yaitu versi Stabil (yang sudah ada sebelumnya di production) dan versi Canary (yang mau ditest dideploy ke production)
  • nanti secara bertahap, tergantung dari hasil deployment dan feeback dari pengguna, maka versi Canary akan diterapkan di seluruh server atau seluruh pengguna, dan menjadi versi Stabil terbaru menggantikan yang sebelumnya.

Cara detailnya seperti apa ?


Ok..ok, sekarang kita tahu bagaimana konsepnya dan caranya secara umum.

Akan tetapi detailnya seperti apa ?

Biasanya akan ada 2 cara detailnya, yaitu :

  • Rolling Canary Deployment.
  • Side by Side Canary Deployment

Rolling Canary Deployment adalah Canary Deployment dengan memanfaatkan server atau instance yang sudah ada.

Misalnya ada 10 instance server yang digunakan di Production.

Secara bertahap, release dilakukan di misalnya 2 instance server saja.

Sehingga ada 2 instance server menggunakan versi terbaru, sementara 8 instance server lainnya masih menggunakan versi yang lama.

Kemudian berdasarkan hasil release dan feedback dari user, maka secara bertahap 8 server yang lainnya di Rolling out untuk dideploy versi yang baru.

Atau kalau ternyata releasenya tidak sesuai harapan, maka 2 instance server yang sudah di deploy tadi bisa di rollback.


Side by Side Canary Deployment adalah Canary Deployment dengan menginstansiasi atau menduplikasi environment yang sama.

Dengan Side by Side Canary Deployment maka environment Production yang existing akan di clone.

Kemudian secara bertahap di versi Clone tadi akan diinstall release yang baru.

Kemudian ada pengatur dari sisi backend atau frontend yang akan melakukan pembagian rute akses antara versi yang asli dengan versi yang clone dengan persentase yang diinginkan.

Sehingga di Production, pengguna akan diarahkan sesuai persentase. Ada yang akan diarahkan ke versi clone, dan ada yang masih menggunakan versi lama yang aslinya tadi.

Dengan cara seperti ini, maka kita bisa meminta feedback dan mengisolasi test kita terhadap fitur release yang kita lakukan.

Misalnya dengan melakukan A/B Testing, yaitu testing terhadapa fitur yang berbeda versinya di production.

Dan lagi-lagi tergantung dari hasil release dan feedback dari pengguna, maka secara bertahap environment yang di Clone akan dijadikan diacu sampai 100% bagi pengguna.

Setelah environment Clone berhasil di implementasi sampai 100%, maka environment aslinya akan di Destroy.

Sehingga di Production, akan diisi dengan versi terbaru semuanya.