Pelatihan Tertulis DevOps

Bagaimana Cara Menerapkan Kode Berisiko Rendah ke Produksi dengan DevOps?

Di banyak organisasi TI, penerapan ke produksi rumit dan menegangkan. Untuk menghindari masalah, organisasi cenderung mengurangi frekuensi penerapan sebisa mungkin. Akibatnya, mereka harus menerapkan batch yang lebih besar dan menghadapi masalah yang lebih besar. Lingkaran masalah ini makin memburuk dan sayangnya mencerminkan keadaan banyak organisasi terbesar, termasuk yang bisnis utamanya perangkat lunak dan teknologi.

Tim DevOps Memiliki Mekanisme Pengendalian dan Mitigasi Risiko Bawaan

Dalam organisasi TI biasa, tim pengembangan membuat perangkat lunak dan tim operasi menerapkannya. DevOps memindahkan pengendalian dan mitigasi risiko dari tim independen lain ke tim Anda sendiri yang kompeten dan mandiri. Penerapan otomatis dan tinjauan sejawat juga dilakukan dalam tim.

Lingkungan produksi dan nonproduksi adalah aset yang sama pentingnya dengan perangkat lunak. Karena itu, tim DevOps mengikuti tiga prinsip ini:

1. Jaga konsistensi semua lingkungan, mulai dari sistem operasi, komponen, antarmuka, tingkat patch, dan dependensi lain hingga perangkat lunak serta konfigurasi Anda sendiri.
2. Jadikan perbaikan hambatan yang mengganggu konsistensi lingkungan sebagai prioritas utama.
3. Gunakan teknik yang sama untuk menerapkan ke semua lingkungan agar latihan penerapan ke produksi menjadi bagian dari pekerjaan sehari-hari.

Mekanisme Penerapan Layanan Mandiri Bawaan

Mekanisme penerapan layanan mandiri otomatis mengikuti langkah berikut.

1. Tulis kode dan masukkan ke trunk.
2. Buat paket yang siap diterapkan.
3. Validasi paket, dependensi, dan kesiapan konfigurasi.
4. Validasi kesiapan lingkungan.
5. Jalankan pengujian otomatis.
6. Catat hasil semua validasi dan pengujian otomatis untuk keperluan audit dan kepatuhan.
7. Terapkan paket ke lingkungan tujuan.
8. Jalankan pengujian otomatis di lingkungan tujuan untuk memvalidasi penerapan.
9. Pantau metrik sistem, kinerja, dan aktivitas lingkungan tujuan.
10. Beri umpan balik cepat dan perbaiki atau batalkan penerapan jika terjadi masalah.

Penerapan dan Rilis Adalah Dua Hal Berbeda

Dengan mekanisme layanan mandiri untuk menerapkan kode secara otomatis ke lingkungan produksi dan nonproduksi, tim DevOps dapat melakukan penerapan setiap hari. Karena tidak setiap penerapan memberikan fitur atau manfaat baru bagi klien, rancang arsitektur aplikasi, lingkungan, atau keduanya agar rilis tidak memerlukan perubahan kode maupun penerapan tambahan.

Pola Penerapan Biru-Hijau

Salah satu tantangan otomatisasi adalah peralihan itu sendiri, yaitu memindahkan perangkat lunak dari tahap pengujian terakhir ke produksi. Peralihan biasanya harus cepat untuk mengurangi waktu henti. Pendekatan biru-hijau menggunakan dua lingkungan produksi yang dibuat semirip mungkin. Kapan pun, salah satunya aktif, misalnya biru. Saat menyiapkan rilis baru, pengujian terakhir dilakukan di lingkungan hijau. Setelah perangkat lunak berfungsi di sana, alihkan router agar semua permintaan masuk menuju lingkungan hijau. Lingkungan biru kini tidak aktif.

Pola Penerapan Canary
(disebut juga peluncuran diam-diam)

Kenari dahulu sering digunakan di tambang batu bara sebagai peringatan dini. Gas beracun seperti metana atau karbon dioksida membunuh burung sebelum memengaruhi penambang. Tanda-tanda gangguan pada burung memberi tahu penambang bahwa kondisi tidak aman.

Terinspirasi oleh penggunaan kenari di tambang, pola canary merilis perubahan kepada sebagian pengguna atau server. Perubahan pertama-tama diterapkan pada beberapa server, diuji, lalu diperluas ke server lainnya. Pola ini memberi peringatan dini dengan dampak lebih kecil pada waktu henti. Jika penerapan canary gagal, server lain tidak terdampak.

Facebook dan Google, bersama banyak perusahaan teknologi besar lain, menggunakan penerapan canary yang disebut “peluncuran diam-diam”. Mereka secara bertahap merilis dan menguji fitur baru kepada sekelompok kecil pengguna sebelum merilisnya kepada semua orang. Dengan demikian, mereka dapat mengetahui apakah pengguna menyukainya dan menilai dampaknya pada kinerja sistem. Facebook menyebut alatnya “Gatekeeper” karena alat itu mengendalikan akses pengguna ke setiap fitur baru.

Disebut peluncuran diam-diam karena fitur biasanya tidak diumumkan. Fitur diperkenalkan secara diam-diam kepada 1% pengguna, lalu 5%, lalu 30%, dan seterusnya. Kadang fitur baru diluncurkan dengan cara ini selama beberapa hari lalu tidak pernah muncul lagi. Mungkin kinerjanya buruk atau perusahaan hanya ingin mendapat umpan balik awal untuk mengarahkan pengembangan.

Pola Rilis dengan Sistem Imun Klaster

Pola ini memperluas pola penerapan canary. Pemantauan kinerja dan aktivitas perangkat lunak harus terintegrasi erat dengan proses rilis.

Pada pola canary di atas, setelah penerapan awal ke server berwarna oranye, sistem pemantauan mencatat metrik sistem, kinerja, dan aktivitas perangkat lunak. Sistem mengeluarkan peringatan dini jika masalah melampaui ambang tertentu, lalu secara otomatis membatalkan perubahan kode pada server oranye.

Jika pengujian otomatis pada server oranye dan pemantauan memberi hasil positif, tim DevOps dapat menerapkan kode ke semua klaster server biru dengan lebih percaya diri. Singkatnya, pola ini memberi tim:

• Perlindungan tambahan terhadap masalah yang mungkin luput dari pengujian otomatis.
• Umpan balik cepat dan pembatalan perubahan secara otomatis ketika terjadi masalah di produksi.

Sakelar Fitur

Sakelar fitur memungkinkan Anda mengaktifkan atau menonaktifkan fitur aplikasi. Setelah semua kode yang diperlukan diterapkan ke produksi, rilis fitur cukup dilakukan dengan menyalakan sakelarnya. Sakelar fitur biasanya berupa pengaturan dalam berkas konfigurasi runtime atau basis data konfigurasi sistem.

Tim DevOps dapat menonaktifkan fitur jika penerapan canary menghasilkan kesalahan atau pengalaman pengguna yang kurang baik. Sakelar juga memungkinkan tim menonaktifkan fitur yang menghabiskan banyak sumber daya tetapi relatif kurang penting ketika sistem kesulitan menangani beban. Meski sistem tidak bisa diskalakan dengan semua fitur, klien tetap mendapat kinerja terbaik dari fitur penting. Misalnya, pada portal e-commerce, Anda dapat menonaktifkan sementara tampilan tagihan agar alur pembayaran mendapat lebih banyak CPU dan memori.

Dalam arsitektur berorientasi layanan, tim DevOps dapat menerapkan beberapa versi layanan tanpa mengaktifkannya. Setelah semua versi baru yang dibutuhkan untuk fitur atau alur layanan diterapkan, nyalakan sakelar layanan tersebut untuk mengaktifkan alur baru.

Rancang Arsitektur untuk Rilis yang Lebih Aman

Tidak ada satu arsitektur sempurna yang sesuai untuk semua produk dan layanan perangkat lunak di semua skala.

Saat membangun platform TI perusahaan rintisan, arsitektur monolitik sering menjadi pilihan pertama untuk masuk ke pasar secepat dan semurah mungkin serta memvalidasi dasar pertimbangan bisnis. Masalahnya, aspek-aspek yang berbeda secara fungsi, seperti fungsi inti dan pelengkap, antarmuka pengguna dan sistem, serta integrasi, saling terkait erat dan bukan komponen terpisah. Banyak perusahaan besar, termasuk Amazon, Google, Facebook, dan Ebay, perlu meninggalkan arsitektur monolitik agar bisa tumbuh cepat serta merilis dan memperluas fitur dengan risiko rendah. Mereka beralih ke arsitektur berorientasi layanan atau layanan mikro dengan pola Strangler Application.

Pola Strangler Application untuk Migrasi Berisiko Rendah ke Layanan Mikro

Mengganti seluruh sistem kompleks dapat membutuhkan upaya sangat besar. Sering kali, Anda perlu bermigrasi secara bertahap sambil mempertahankan sistem lama untuk fitur yang belum dipindahkan. Namun, menjalankan dua versi aplikasi berarti klien perlu mengetahui letak setiap fitur. Setiap kali fitur atau layanan dipindahkan, klien harus diperbarui agar mengarah ke lokasi baru.

Pola Strangler Application secara bertahap mengganti fungsi tertentu dengan aplikasi dan layanan baru. Buat lapisan fasad yang mencegat permintaan ke sistem backend lama. Fasad mengarahkan permintaan ke aplikasi lama atau layanan baru. Fitur yang ada dapat dipindahkan secara bertahap dan pengguna layanan tetap memakai antarmuka yang sama tanpa menyadari migrasi.

Ebay adalah salah satu organisasi pertama yang menggunakan pola ini untuk bermigrasi dari arsitektur monolitik lama ke layanan mikro. Mereka mula-mula menempatkan aplikasi di balik API universal yang didefinisikan dengan baik dalam ekosistem Ebay, sehingga tidak perlu menulis ulang semua kode sekaligus. Tim rekayasa dibagi menjadi kelompok kecil beranggotakan 6 hingga 10 orang. Kini tim beranggotakan hingga 10 orang dapat mengelola API universal platform lelang, yang paling sering digunakan di dunia.

KESIMPULAN

Di banyak departemen TI, tim tidak bertanggung jawab membangun pola penerapan dan arsitektur yang siap menghadapi masa depan, dapat diskalakan, dan lebih aman. Padahal, arsitektur dan fitur aplikasi yang memungkinkan penerapan lebih cepat dan aman adalah syarat utama keberhasilan DevOps.

Dengan penerapan harian yang lebih cepat dan berisiko rendah, Anda dan tim dapat memperoleh manfaat penerapan berkelanjutan dan rilis yang lancar.