Pendahuluan

Pengenalan awal mengenai Release Strategy

Mengenai Canary Deployment bisa dilihat di Canary Deployment

Sekarang kita akan melihat Strategy Release yang hampir mirip dengan Canary Deployment juga.

yaitu

BLUE GREEN DEPLOYMENT


Blue Green Deployment


Blue Green Deployment ini merupakan istilah yang muncul dari 2 orang penulis buku Continous Delivery yang bernama

Jez Humble dan Dave Farley.

Mereka mengusulkan dalam bukunya tersebut bahwa untuk melakukan Deployment Release, maka :

  • kita mesti mempersiapkan 2 environment yang identik di Production, satu untuk testing dan satu lagi untuk production (live).
  • kedua environment ini sama isinya dan merupakan mirror satu sama lain.
  • ketika dilakukan deployment release yang baru, maka deployment akan dilakukan di versi environment “testing” tadi.
  • setelah deployment release di environment “testing” selesai, maka dilakukanlan “switch off” dari environment “production” ke environment “testing”.
  • sekarang environment “testing” berubah menjadi environment “production” yang baru.
  • dan environment “production” yang lama menjadi environment “testing” untuk release selanjutnya.

Sederhanaa kaan !

Blue Green deployment ini sebenarnya sebuah proses yang intuitif sekali, kalau kita mau melihat evolusi sebuah tim dalam melakukan deployment release.

Dari dulu, permasalahan umum diwaktu deployment Release adalah :

  • ternyata environment “production” tidak benar-benar sama dengan environment “testing” yang biasanya terpisah dan dimana kita melakukan testing “DEV”, “SIT”, dan “UAT”
  • akibatnya bisa saja terjadi kesalahan teknis kecil atau perlakuan khusus yang berbeda antara production dan testing. Misalnya environment “Production” menggunakan RedHat, sementara environment “testing” menggunakan Ubuntu. Mungkin saja ada perlakuan spesifik terhadap environment yang berbeda.
  • melakukan deployment release secara bertahap ke environment “production”, mau tak mau membutuhkan dowtime yang bervariasi tergantung dari banyaknya artifact deployment, lamanya deployment, akumulasi switch off service atau server yang diinstall versi release terbaru, dll.

Permasalahan diatas biasanya akan memicu resiko :

  • waktu Downtime yang lebih lama.
  • waktu Downtime yang tidak terprediksi.
  • gangguan fungsi bisnis/fitur yang tidak terprediksi dan bisa saja butuh waktu lama untuk memperbaikinya

Oleh karenanya, dengan metoda Blue Green deployment, maka sebenarnya kita coba untuk memiliki 2 environment “production” yang saling back to back.

Saling bisa menggantikan.

Akan tetapi pada satu saat, hanya satu environment saja yang aktif dipakai oleh pengguna.

Satu aktif, dan satu pasif.

Hal ini dipermudah dengan mekanisme routing sistem seperti misalnya router, load balance, ataupun reverse proxy seperti nginx, dll.


Kelebihannya ?


Dengan Bluee Green deployment ini, maka :

  • Kita bisa meminimalkan downtime, atau waktu yang dibutuhkan untuk melakukan deployment release ke production. Karena secara sembunyi-sembunyi kita melakukan deployment secara terpisah di environment “bukan” production, lalu di “swith/cut over” setelah selesai.
  • kita bisa melakukan testing post production tanpa mempengaruhi fungsi yang sekarang jalan di production.
  • kita bisa mempunyai environment backup production yang bisa otomatis diload kapanpun. Istilahnya kita mempunyai Hot Backup.
  • dengan adanya Hot Backup ini, maka kita juga mudah ketika melakukan simulasi Disaster Recovery.
  • proses rollback ketika deployment release tidak sesuai dengan yang diharapkan, juga lebih mudah. Tinggal switch/cut over lagi.

Kekurangannya ?


Selain kelebihan, tentu saja ada kekurangannya memakai strategi Bluee Green deployment ini, seperti :

  • sumber daya yang lebih boros, karena kita mesti menyiapkan environment yang sama dengan production. Apalagi kita tahu bahwa biasanya environment production dibuat sesempurna mungkin dan dengan spesifikasi yang mempuni.
  • transaksional data, yang biasanya berkaitan dengan data di database. Melakukan switching terhadap 2 environment yang berbeda diwaktu masih ada transaksi terjadi, bisa mengakibatkan ketidak sinkronan data. Hal ini mesti dimitigasi agar menjadi seminimal mungkin.
  • transaksi yang membutuhkan long running process. Ini bisa juga menjadi permasalah nantinya. Karena harus dipastikan bahwa transaksinya harus lengkap dan tidak corrupt.

Blue Green deployment ini sebenarnya mirip dengan Side by Side Canary Deployment

dimana ada 2 sistem identik yang ada di Production.

Akan tetapi di Bluee Green deployment, dilakukan pergantian secara keseluruhan pada saat cut over/switching.

Sementara di Side by Side Canary Deployment, dilakukan pergantian secara bertahap dan tidak secara keseluruhan, akan tetapi tergantung dari tingkat confidence dan feedback dari user.


Kenapa disebut Blue Green


Hmm, sebenarnya pertanyaan yang cukup menggelitik.

Dimana bisa saja sebenarnya dinamakan A/B Deployment, atau X Y deployment.

Akan tetapi pemilihan abjad atau angka dalam penamaan nya bersikap hirarki dan kurang independen.

Sehingga pemilihan warna menjadi pilihan lebih logis.

Akan tetapi, tetap saja “warna” juga menjadi cukup subjektif, apalagi misalnya dengan warna “Merah” (yang terkadang dianggap kurang bagus).

Atau “Kuning” yang dianggap “sebagai pertanda warning”.

Sehingga pemilihan warna “Blue” dan “Green” menjadi pilihan warna yang lebih netral.