Apa itu penerapan biru-hijau?

Satu lingkungan aktif dan melayani pengguna, diberi label “biru” dan lainnya, lingkungan “hijau”, digunakan untuk penerapan dan pengujian versi baru. Ketika versi baru disetujui, lalu lintas langsung dialihkan dari lingkungan biru ke lingkungan hijau.

Strategi ini dipopulerkan dan dinamai oleh Jez Humble dan David Farley dalam buku mereka tahun 2010, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.

Biru-hijau adalah teknik penerapan berkelanjutan yang memungkinkan penghapusan waktu henti, kemampuan untuk secara instan mengeluarkan rollback ke versi lama. Teknik ini menyediakan pengujian A/B yang mudah dan menciptakan lingkungan yang aman untuk pengembangan tanpa risiko pengguna akhir menemukan versi yang belum siap.

Meskipun ungkapan “biru-hijau” paling umum digunakan, ada juga variasi lain. Netflix menggunakan “merah/hitam,” tetapi konsepnya tetap sama. Terkadang, pengembang mungkin ingin memiliki lebih dari dua lingkungan. Skema penamaan warna efektif untuk membedakan antara dua lingkungan. Namun, organisasi mungkin juga menggunakan konvensi penamaan seperti nomor versi, ID build, atau judul khusus, terutama jika ada lebih dari dua lingkungan yang terlibat.

Meskipun sederhana dalam konsep, ada beberapa langkah dan variabel dalam langkah-langkah tersebut untuk menciptakan penerapan biru-hijau yang stabil dan aman yang memanfaatkan manfaat strategi.

Menciptakan lingkungan yang sama untuk penerapan biru-hijau dapat dilakukan secara manual atau dengan menggunakan alat bantu otomatis. Infrastruktur Sebagai Kode, atau IaC, adalah salah satu pendekatan otomatis untuk penyediaan. IaC menggunakan file konfigurasi yang dapat dibaca mesin, seperti sekumpulan instruksi atau resep untuk mengaktifkan penyediaan otomatis dan konfigurasi infrastruktur TI sesuai dengan spesifikasi yang telah ditentukan.

IAC memungkinkan pengembang untuk secara otomatis mengubah salinan lingkungan biru, yang sudah beroperasi, untuk digunakan sebagai lingkungan hijau. Pengembang kemudian dapat mengedit template ini sesuai kebutuhan, karena tahu bahwa mereka mulai dari tempat yang dapat dipercaya. Menggunakan IaC membantu memastikan replikasi yang dapat diulang dan tepat.

Kontainerisasi, di mana aplikasi, dependensi, dan API semuanya dikemas bersama menjadi satu “image kontainer” adalah pendekatan lain. Menggunakan kontainer menjamin bahwa seluruh lingkungan identik. Kubernetes, platform orkestrasi kontainer sumber terbuka, biasanya digunakan untuk kontainerisasi dalam penerapan biru-hijau.

Setelah lingkungan dibuat, aplikasi dikerahkan ke lingkungan biru (aktif).

Penyeimbang beban adalah mekanisme, sering ditemukan di depan lingkungan aplikasi sebagai alat dalam penyedia cloud atau lingkungan Kubernetes, yang mengarahkan lalu lintas produksi sesuai keinginan. Dalam skenario ini, penyeimbang beban mengarahkan lalu lintas ke lingkungan biru yang aktif.

Kemudian, kode baru dengan pembaruan aplikasi diterapkan ke lingkungan produksi hijau. Karena load balancer mengarahkan lalu lintas ke lingkungan produksi biru, lingkungan hijau adalah ruang aman untuk bereksperimen, menguji, dan mengonfigurasi. 

Ketika proses penerapan ke lingkungan hijau selesai, lakukan semua langkah validasi yang diperlukan. Langkah-langkah ini mungkin termasuk pemindaian keamanan, pemeriksaan kinerja, pemindaian bug, dan banyak lagi.

Ketika lingkungan hijau divalidasi dan disetujui oleh semua pemangku kepentingan yang diperlukan, perbarui penyeimbang beban untuk mengarahkan lalu lintas dari versi sebelumnya yang berwarna biru ke versi baru yang berwarna hijau.

Peralihan ini akan berlangsung seketika; pengguna tidak akan melihat kesalahan atau sesuatu yang lain selain lingkungan biru atau hijau.

Pembaruan DNS dapat digunakan untuk mengarahkan pengguna ke lingkungan yang diinginkan, tetapi mungkin ada penundaan yang signifikan karena cache menyegarkan alamat IP. Karena masalah ini, penyeimbang beban lebih disukai karena pembaruan langsung berlaku.

Meskipun langkah validasi seharusnya mendeteksi sebagian besar bug potensial atau masalah kinerja, tetap penting untuk memantau lingkungan hijau yang baru aktif. Perangkat lunak dan layanan analitik dapat membantu di sini. Membandingkan aktivitas dapat menunjukkan apakah sesuatu yang tidak biasa sedang terjadi.

Jika terjadi kesalahan, lalu lintas pengguna dapat diarahkan ke lingkungan biru sementara pengembang memecahkan masalah.

Menonaktifkan lingkungan biru yang sudah tidak terpakai adalah opsional; beberapa organisasi mungkin ingin mempertahankan lingkungan biru tanpa batas waktu untuk berjaga-jaga jika lingkungan hijau suatu saat perlu dikembalikan ke versi sebelumnya. Namun, ada juga potensi alasan biaya untuk menonaktifkan lingkungan biru pada titik tertentu dalam siklus hidupnya. Bergantian, lingkungan biru dapat menjadi lingkungan eksperimental, atau hijau, berikutnya.

Jalur integrasi berkelanjutan/pengiriman berkelanjutan adalah “alur kerja DevOps otomatis yang merampingkan proses pengiriman perangkat lunak.” Pipeline ini memfasilitasi pengiriman berkelanjutan perubahan kode dalam aplikasi.

Ini adalah praktik yang terintegrasi erat dengan penerapan biru-hijau: CI/CD memungkinkan penerapan biru-hijau dan penerapan biru-hijau sering dibangun ke dalam pipeline CI/CD untuk membantu merilis pembaruan perangkat lunak tanpa waktu henti dan mengurangi risiko.

Pipeline CI secara otomatis menguji dan mengintegrasikan kode baru sebelum diintegrasikan ke dalam repositori pusat, mengurangi risiko kode cacat mencapai penerapan. Pipeline CD memanfaatkan strategi penerapan biru-hijau untuk mengoptimalkan rilis cepat tanpa memengaruhi pengguna. Penerapan biru-hijau menyediakan ketersediaan yang hampir berkelanjutan, dan rollback yang aman, yang memainkan peran besar dalam mencapai tujuan CI/CD menyeluruh dari rilis kode yang sering dan andal.

Berasal dari idiom "burung kenari (canary) di tambang batu bara", penerapan canary adalah cara lain untuk mengurangi risiko saat menerapkan versi perangkat lunak baru.

Sementara penerapan biru/hijau menciptakan dua lingkungan terpisah, yang masing-masing biasanya menghosting semua atau tidak ada lalu lintas, canary mengambil pendekatan yang berbeda. Rilis canary hanya memiliki satu lingkungan, menghosting beberapa versi.

Dalam penerapan canary , versi baru dirilis pertama kali ke sebagian kecil pengguna. Kemudian, pengembang dapat melihat apakah kesalahan meningkat, kinerja menurun, atau masalah lain muncul. Persentase kecil pengguna tersebut bertindak sebagai "burung kenari di tambang batu bara." Jika tidak ada masalah, lalu lintas ke versi baru terus meningkat, memeriksa kesalahan sepanjang waktu.

Keuntungan utama dari penerapan canary dibandingkan blue/green adalah dalam hal biaya infrastruktur, karena penerapan canary hanya menggunakan satu lingkungan sedangkan blue/green menggunakan dua lingkungan. Namun, penerapan canary juga bisa lebih kompleks dan berisiko lebih tinggi jika diperlukan rollback, dibandingkan dengan pengalihan penyeimbangan beban sederhana biru/hijau.

Metode penerapan canary dapat berguna jika potensi kesalahan tidak menjadi perhatian signifikan seperti mendapatkan rilis baru di depan pengguna secepat mungkin, atau jika pengembang ingin memantau dampak dengan masukan pengalaman yang nyata.

Maka, ada juga pendekatan hybrid. Penyeimbang beban dapat mengarahkan beberapa lalu lintas pengguna, katakanlah 1%, ke lingkungan hijau sementara 99% ke Biru. Ini secara efektif memadukan kedua strategi, memberikan insight penerapan dengan kemampuan untuk mengeluarkan rollbacks dengan cepat dan mudah.

Penerapan biru-hijau menawarkan banyak keuntungan, baik yang digunakan dalam peluncuran tipe total atau canary.

Karena penyeimbang beban mengalihkan lalu lintas secara instan ke lingkungan yang diinginkan, pengguna akhir tidak pernah mengalami waktu henti. Ini adalah manfaat utama untuk instance lalu lintas tinggi di mana waktu henti dapat menimbulkan masalah bisnis yang signifikan.

Memiliki dua lingkungan terpisah, salah satunya dikenal aman dan operasional, memungkinkan pengembang untuk segera membatalkan perubahan apa pun jika masalah muncul. Jika lingkungan hijau menghadirkan masalah, lalu lintas dapat diarahkan ke lingkungan biru.

Memiliki dua lingkungan terpisah menyederhanakan analisis metrik, analitik, dan pengujian A/B untuk versi yang berbeda. Data analisis dan pemantauan dapat dengan jelas dihubungkan ke lingkungan biru atau hijau, memungkinkan perbandingan langsung dan pemeriksaan kesehatan. Hal ini berbeda dengan penerapan canary, yang lebih sulit dibedakan karena kedua versi aktif secara bersamaan.

Lingkungan eksperimental hijau memungkinkan pengujian menyeluruh dari versi baru di luar pandangan pengguna akhir. Versi baru diluncurkan dengan tingkat keyakinan yang signifikan bahwa mereka akan beroperasi sebagaimana dimaksud. Dalam kasus di mana ini tidak terjadi, lalu lintas dapat langsung dialihkan kembali ke lingkungan biru yang stabil.

Meskipun penerapan biru-hijau menawarkan banyak manfaat, ada potensi kekurangan dan contoh penggunaan yang tidak optimal yang harus dipertimbangkan oleh tim pengembangan.

Dengan dua lingkungan yang disediakan sepenuhnya berjalan, biaya hosting dan infrastruktur dapat meningkat. Belum tentu biaya-biaya ini akan justru dua kali lipat biaya satu lingkungan. Dalam beberapa kasus, lingkungan hijau akan menjalankan jejak yang lebih kecil atau lingkungan biru mungkin dengan cepat dinonaktifkan atau beberapa sumber daya mungkin dibagi antara kedua lingkungan. Tetapi kemungkinan akan ada beberapa kenaikan biaya.

Meskipun tidak eksklusif untuk penerapan biru-hijau, mempertahankan sinkronisasi database antara lingkungan lama dan baru dapat menghadirkan tantangan. Misalnya, dalam sistem biru-hijau yang melibatkan perubahan skema yang sering atau kompleks, mungkin sulit untuk mempertahankan kompatibilitas.

Untuk menghindari gangguan pada lingkungan yang aktif, perubahan dalam skema harus kompatibel dengan versi sebelumnya, yang berarti bahwa sistem yang baru dapat bekerja dengan sistem yang lama. Jika tidak, lingkungan mungkin memerlukan database terpisah yang harus disinkronkan secara real time. Sinkronisasi dua arah ini menimbulkan risikonya sendiri, seperti inkonsistensi dan penurunan kinerja.

Untuk mengatasi masalah ini, alat CI/CD, seperti GitHub Actions, menyertakan proses penyebaran database yang secara otomatis mengelola pembaruan skema. Terkadang, perubahan skema yang terlalu rumit dapat meniadakan nilai penerapan biru-hijau.

Dalam aplikasi stateful, aplikasi yang mempertahankan data persisten di seluruh permintaan, penerapan biru-hijau dapat menimbulkan masalah. Aplikasi stateful dapat menyertakan keranjang belanja yang menyimpan kontennya di beberapa kunjungan, atau log pesan. Jika database tidak dibagikan dan tidak kompatibel di antara lingkungan, data ini dapat hilang.

Aplikasi layanan mikro sering kali merupakan sistem yang sangat kompleks yang terdiri dari banyak komponen yang dapat digunakan secara terpisah. Karena pengembang layanan mikro mungkin ingin menerapkan puluhan kali per hari, sifat inkremental dari penerapan canary dianggap sebagai pilihan yang lebih aman.