Penerapan Biru-Hijau dan Perannya dalam DevOps Dijelaskan

Pendekatan “big bang” tradisional untuk pengembangan perangkat lunak tidak kompatibel dengan fleksibilitas tinggi, ketangkasan, dan persyaratan penerapan berkelanjutan dari platform perangkat lunak cloud dan DevOps saat ini.

Mempersiapkan daftar periksa langkah-langkah manual untuk dijalankan selama penerapan rilis produksi tidaklah cukup. Jika Anda melakukannya, Anda tidak benar-benar gesit, juga bukan DevOps yang tepat.

Penerapan Biru-Hijau: Gambaran Umum

Penyebaran Biru-Hijau adalah pendekatan penerapan perangkat lunak yang mengurangi waktu henti dan risiko versi perangkat lunak baru dengan menciptakan dua lingkungan yang identik: aktif (biru) dan tidak aktif (hijau).

Lingkungan aktif adalah tempat versi perangkat lunak saat ini berjalan, dan pengguna menghasilkan lalu lintas produksi. Lingkungan tidak aktif adalah tempat versi baru dari perangkat lunak disebarkan dan diuji.

Setelah versi baru diuji dan siap, lalu lintas dialihkan dari lingkungan aktif ke lingkungan tidak aktif, menjadikannya lingkungan aktif baru. Anda dapat mengulangi proses ini sesuai kebutuhan.

Sumber: docs.aws.amazon.com

Konteks DevOps

Penyebaran Biru-Hijau sangat cocok dengan pola pikir dan proses DevOps karena mendukung pengiriman dan penerapan berkelanjutan perangkat lunak sambil meminimalkan waktu henti bagi pengguna produksi dan menghilangkan risiko kegagalan rilis produksi.

Memiliki dua lingkungan yang identik memungkinkan untuk menguji dan menerapkan versi perangkat lunak baru tanpa memengaruhi lingkungan produksi saat ini. Ini berarti rilis lebih cepat dan lebih sering, yang merupakan aspek kunci dari DevOps.

Selain itu, kemampuan untuk mengalihkan lalu lintas antar lingkungan dengan cepat merupakan prasyarat utama untuk rollback cepat jika terjadi masalah, yang juga penting dalam lingkungan DevOps.

Prinsip Utama Penerapan Biru-Hijau

#1. Dua Lingkungan Identik

Penyebaran Biru-Hijau membutuhkan pembuatan dua lingkungan yang identik. Itu berarti identik dari sudut pandang data dan proses. Satu aktif (biru), dan yang lainnya tidak aktif (hijau).

Lingkungan biru adalah tempat pengguna produksi menjalankan proses harian mereka. Lingkungan hijau selalu sinkron dengan biru, tetapi penguji menjalankan test case mereka di sana. Meskipun lingkungan ini bukan produksi, Anda menjalankan pengujian dalam kondisi dunia nyata karena merupakan lingkungan seperti produksi.

#2. Saklar Lalu Lintas

Setelah versi baru perangkat lunak diuji dan siap, lalu lintas dialihkan dari lingkungan aktif ke lingkungan tidak aktif, menjadikannya lingkungan aktif yang baru.

Peralihannya instan. Semua penyebaran sekarang menjadi sesuatu dari masa lalu. Tidak ada jendela waktu henti. Pengguna tidak perlu melakukan apapun untuk mencapai lingkungan baru. Mereka dialihkan secara otomatis, dan semuanya sekaligus.

Sumber: aws.amazon.com

#3. Kembalikan Cepat

Kemampuan untuk mengalihkan lalu lintas antar lingkungan dengan cepat juga berarti pengembalian cepat jika terjadi masalah. Ini memastikan downtime minimal, dan aplikasi tetap sangat tersedia.

Jika ada yang tidak beres dengan lingkungan hijau, semua pengguna akan langsung beralih kembali ke lingkungan biru asli yang stabil tanpa ada gangguan.

#4. Pengujian Otomatis

Pengujian otomatis adalah aspek utama penerapan Biru-Hijau. Ini memastikan bahwa versi baru dari perangkat lunak diuji secara menyeluruh sebelum disebarkan ke lingkungan aktif.

Jika Anda tidak memiliki sejumlah besar pengujian otomatis di sistem Anda (termasuk pengujian unit, pengujian fungsional, dan setidaknya pengujian regresi), maka mungkin tidak masuk akal untuk berpikir tentang penerapan penyebaran Biru-Hijau.

Kurangnya tes otomatis akan memperlambat Anda secara dramatis. Waktu yang diperlukan untuk menguji lingkungan baru (hijau) akan sangat lama sehingga pada saat Anda dapat beralih ke lingkungan hijau, itu sudah “terlalu tua” dari perspektif siklus hidup pengembangan perangkat lunak.

#5. Pengiriman Berkelanjutan

Penyebaran Biru-Hijau adalah bagian dari alur pengiriman berkelanjutan, yang pada akhirnya berarti rilis perangkat lunak yang lebih cepat dan lebih sering ke dalam produksi.

Anda dapat beralih segera setelah Anda siap untuk menguji versi perangkat lunak baru di lingkungan hijau. Karena penyebaran sudah dilakukan dan Anda hanya perlu melakukan pengalihan lalu lintas itu sendiri, ini sangat cepat sehingga Anda dapat melakukannya setiap hari. Dengan asumsi Anda juga cepat dalam kegiatan pengujian, tentu saja.

Siklus Hidup Khas

Platform yang menjalankan penerapan Blue-Green memiliki siklus langkah dan proses khusus untuk dijalankan. Ini biasanya terdiri dari:

Membangun versi baru dari perangkat lunak. Ini melibatkan kompilasi kode, menjalankan pengujian otomatis, dan membuat artefak yang dapat diterapkan.

Tahap selanjutnya adalah Anda menerapkan versi baru perangkat lunak ke lingkungan yang tidak aktif (hijau). Ini melibatkan pengaturan lingkungan, menyebarkan artefak, dan mengonfigurasi pengaturan yang diperlukan.

Setelah versi baru perangkat lunak diterapkan ke lingkungan hijau, jalankan pengujian otomatis untuk memastikan versi baru berfungsi dengan benar. Ini termasuk tes fungsional, tes regresi, tes integrasi, dan, jika Anda luar biasa, bahkan tes kinerja.

Alihkan lalu lintas dari lingkungan aktif (biru) ke lingkungan tidak aktif (hijau). Ini melibatkan pembaruan penyeimbang beban atau pengaturan DNS untuk mengarahkan lalu lintas ke lingkungan hijau. Tentu saja, Anda ingin ini dilakukan melalui proses otomatis.

Setelah sakelar selesai, pantau aplikasi untuk memastikannya berfungsi dengan benar. Ini termasuk pemantauan kesalahan, masalah kinerja, dan masalah lainnya.

Langkah ini opsional, dan Anda tidak ingin melakukannya terlalu sering. Tetapi jika ada yang mendeteksi masalah substansial, alihkan lalu lintas kembali ke lingkungan biru untuk melakukan rollback instan. Sekali lagi, tanpa downtime atau pemutusan yang terkait dengan pengguna produksi. Cukup perbarui penyeimbang beban atau pengaturan DNS untuk mengarahkan lalu lintas ke lingkungan biru.

Setelah Anda menyelesaikan masalah tersebut dan Anda siap untuk kembali ke versi baru lagi, alihkan lalu lintas kembali ke lingkungan hijau. Jadi sekali lagi – perbarui penyeimbang beban atau pengaturan DNS untuk mengarahkan lalu lintas kembali ke lingkungan hijau.

Terakhir, setelah versi baru perangkat lunak stabil dan berfungsi dengan benar, nonaktifkan perangkat lunak versi lama yang berjalan di lingkungan biru. Anda akan memerlukannya untuk membangun versi baru lainnya dari sistem Anda.

Mengimplementasikan Pipeline CI/CD

Menerapkan penyebaran Biru-Hijau ke dalam pipa DevOps CI/CD akan menjadi proses alami.

Prasyarat yang kuat adalah Anda sudah memiliki dua lingkungan identik tersebut. Karena ini akan menjadi proses otomatis, Anda dapat menggunakan infrastruktur sebagai alat kode AWS CloudFormation atau bahkan awan-agnostik Terraform skrip untuk membuat/membuat ulang/memperbarui lingkungan untuk Anda dalam pipeline otomatis.

Setelah Anda memilikinya, ini adalah langkah yang relatif mudah untuk membuat proses penerapan yang sepenuhnya otomatis. Anda tinggal menggunakan kembali jalur pipa yang sudah ada untuk penciptaan lingkungan biru dan hijau. Namun, kali ini Anda perlu memasukkan juga proses pengujian ke dalam pipeline.

Proses peralihan lalu lintas dapat Anda otomatiskan dengan alat seperti AWS Elastic Load Balancer atau NGINX. Ini melibatkan pembaruan penyeimbang beban atau pengaturan DNS untuk mengarahkan lalu lintas ke lingkungan hijau setelah versi baru perangkat lunak diuji dan siap.

Bagian selanjutnya dari teka-teki ini adalah pemantauan. Untuk itu, gunakan alat seperti AWS CloudWatch, New Relikatau Datadog.

Terakhir, gunakan kembali saluran pipa yang ada bahkan untuk menonaktifkan lingkungan biru lama. Terserah Anda apakah Anda pertama kali menjalankan penghancuran untuk semua layanan dan komponen sebelum membuatnya kembali dari awal, atau sebagai alternatif, Anda dapat memperbarui skrip untuk setiap layanan dalam rantai. Biasanya, penghancuran & pembuatan ulang adalah opsi yang lebih aman, karena dengan pembaruan, Anda memiliki lebih banyak kasus sudut untuk dipertimbangkan.

Praktik Terbaik Penerapan Biru-Hijau

Ingin tahu tentang cara memanfaatkan penyebaran Biru-Hijau dengan sebaik-baiknya? Berikut adalah beberapa tips yang berasal dari latihan.

Memiliki Strategi Migrasi Database yang Solid

Saat menerapkan versi baru perangkat lunak, penting untuk memastikan bahwa skema database diperbarui dengan benar. Gunakan strategi migrasi database seperti Jalur terbang atau Liquibase untuk mengelola perubahan skema database.

Gunakan Alat Analisis Kenari

Meskipun penyebaran Canary adalah pendekatan alternatif, Anda masih dapat menggunakan beberapa tekniknya untuk menyempurnakan penerapan Biru-Hijau Anda.

Gunakan alat analisis kenari seperti Kayenta atau Spinnaker untuk menganalisis kinerja versi baru perangkat lunak di lingkungan dunia nyata. Ini melibatkan perbandingan kinerja versi baru perangkat lunak dengan kinerja perangkat lunak versi lama.

Gunakan kerangka toggle fitur seperti Beralih untuk mengaktifkan atau menonaktifkan fitur di versi baru perangkat lunak. Hal ini memungkinkan peluncuran fitur baru secara bertahap dan memungkinkan pengembalian cepat jika perlu.

Gunakan Load Balancer dengan Health Checks

Gunakan penyeimbang beban seperti AWS Elastic Load Balancer atau NGINX dengan health check untuk memastikan bahwa lalu lintas hanya diarahkan ke instans yang sehat. Ini memastikan bahwa aplikasi tetap sangat tersedia dan downtime diminimalkan.

Gunakan Paket Rollback dengan Rollback Otomatis

Siapkan rencana rollback jika terjadi masalah, dan otomatiskan proses rollback menggunakan alat seperti AWS CodeDeploy atau Octopus Deploy. Ini memastikan downtime diminimalkan dan aplikasi tetap tersedia.

Ini sebagian besar berlaku untuk lingkungan hijau setiap kali Anda menemukan beberapa masalah signifikan dengan versi baru.

Anda tidak memerlukan rencana rollback untuk lingkungan biru, karena yang ini tetap tidak tersentuh oleh sakelar, dan Anda dapat kembali ke lingkungan stabil ini kapan pun dibutuhkan dan secara instan.

Tantangan dengan Penerapan Biru-Hijau

Menerapkan penyebaran Biru-Hijau dapat menghadirkan beberapa tantangan bagi tim pengembangan. Berikut adalah beberapa tantangan umum:

Menyiapkan dan mengelola dua lingkungan yang identik dapat menjadi rumit dan menghabiskan waktu. Ini membutuhkan keahlian dalam infrastruktur sebagai alat kode seperti Terraform atau CloudFormation. Anda perlu memiliki tim pengembangan senior yang mampu mengatasi tantangan teknis seperti itu.

Saat menerapkan versi baru perangkat lunak, penting untuk memastikan bahwa skema database diperbarui dengan benar. Ini bisa jadi menantang, terutama jika skema databasenya kompleks. Anda memerlukan proses penerapan database yang solid yang dapat secara otomatis dan andal menangani aktivitas pembaruan skema.

Menganalisis kinerja versi baru perangkat lunak di lingkungan dunia nyata dapat menjadi tantangan. Ini membutuhkan keahlian dalam alat analisis kenari seperti Kayenta atau Spinnaker.

Mengimplementasikan pengalihan fitur dapat menjadi tantangan, terutama jika aplikasi memiliki banyak fitur. Ini membutuhkan perencanaan dan koordinasi yang cermat antara tim pengembangan.

Menguji versi baru perangkat lunak di lingkungan dunia nyata dapat menjadi tantangan, terutama jika aplikasi tersebut memiliki banyak pengguna atau server. Anda perlu memiliki kasus uji otomatis sebanyak mungkin. Selain itu, proses rutin Anda akan mencakup banyak koordinasi antara tim pengembangan dan pengujian.

Memiliki solusi pemantauan yang baik adalah kenyataan yang sangat langka, tetapi untuk operasi DevOps yang tepat, ini adalah suatu keharusan. Sesegera mungkin, pergi dan investasikan waktu untuk membangun solusi tersebut dengan layanan yang telah terbukti (AWS CloudWatch, New Relic, Datadog).

Perbedaan Antara Penerapan Biru-Hijau dan Canary

Meskipun perbedaan proses penerapan tradisional cukup jelas (tidak ada dua lingkungan paralel yang berjalan dengan versi perangkat lunak berbeda dalam proses penerapan tradisional), perbedaan penerapan Canary mungkin sedikit lebih menarik.

Penyebaran Biru-Hijau berarti dua lingkungan (biru dan hijau). Tetapi pada saat yang sama, kedua lingkungan tersebut selalu sinkron dalam hal data. Setelah versi baru diuji dan dianggap siap, lalu lintas dialihkan dari lingkungan aktif ke lingkungan tidak aktif, menjadikannya lingkungan aktif baru. Anda tidak menghabiskan waktu untuk menerapkan kode baru, dan tidak ada waktu henti produksi yang terlibat. Semua pengguna produksi bekerja sepanjang waktu di lingkungan aktif saat ini, dan mereka bahkan tidak menyadari adanya peralihan.

Penyebaran Canary melibatkan penggelaran versi baru perangkat lunak ke sebagian kecil pengguna sementara sebagian besar pengguna atau server terus menggunakan versi saat ini. Ini adalah penyebaran bertahap daripada peralihan penuh. Penguji, dalam hal ini, adalah pengguna produksi langsung, meskipun hanya sebagian dari mereka yang ditentukan. Grup ini secara aktif menguji versi baru dengan proses produksi, dan ketika akhirnya stabil, versi baru akan menyebar ke pengguna lainnya.

Jadi mana yang lebih baik?

Jawaban konsultan “itu tergantung” paling cocok di sini, meski kedengarannya kejam.

Jika prioritas sistem Anda adalah ketersediaan tinggi di atas segalanya, maka penyebaran Biru-Hijau akan menjadi pilihan Anda.

Jika preferensi kuat Anda adalah umpan balik yang lebih cepat dan peluncuran versi sistem baru yang lebih terkontrol (walaupun lebih lambat), maka penerapan Canary memiliki keunggulan dibandingkan Biru-Hijau.

Yang penting adalah keduanya cukup gesit untuk menganggap diri mereka cukup baik untuk pembuatan sistem DevOps yang serius.

Studi kasus

Netflix menggunakan penyebaran Biru-Hijau untuk menyebarkan versi baru layanan streamingnya. Dengan menggunakan penyebaran Biru-Hijau, Netflix dapat menerapkan versi baru layanannya tanpa memengaruhi pengalaman pengguna. Faktanya, Netflix juga menggunakan penerapan Canary secara paralel untuk kasus lain, jadi menggabungkan pendekatan yang berbeda untuk penerapan DevOps di bawah atap yang sama bukanlah hal yang tidak realistis.

Selain itu, Amazon dan Etsy menggunakan penyebaran Biru-Hijau untuk menerapkan versi baru platform e-niaga mereka.

Kasus lainnya adalah LinkedIn yang menggunakan penerapan Blue-Green untuk menyebarkan versi baru dari platform jejaring sosialnya.

Last but not least, IBM menggunakan penerapan Blue-Green untuk menerapkan versi baru platform cloud-nya.

Perusahaan-perusahaan ini telah berhasil menerapkan penyebaran Biru-Hijau ke infrastruktur platform mereka dan menjadi contoh yang baik bagi yang lain.

Kata Akhir

Seperti Canary, penyebaran Blue-Green berusaha untuk optimalisasi terbaik dari proses dan metodologi tangkas Anda yang sudah ada untuk mengirimkan perangkat lunak baru dengan lancar sedemikian rupa sehingga tidak ada yang akan menyadarinya sama sekali. Ini adalah tujuan akhir dari pendekatan semacam itu. Anda mengirimkannya terus-menerus dan sangat sering, tetapi tidak ada yang mengetahuinya, tidak ada yang menyadarinya, dan pada akhirnya, tidak ada yang peduli.

Mungkin sedikit membuat frustasi bagi tim pengembangan karena tidak ada gosip di sekitar perusahaan tentang rilis terbaru mereka. Tetapi jika Anda bertanya kepada saya, inilah layanan terbaik yang dapat Anda berikan. Tidak ada yang membicarakannya, tetapi semua orang menggunakannya setiap hari.

Selanjutnya, lihat pertanyaan dan jawaban wawancara DevOps yang sering diajukan.