Praktik penyebaran yang aman

Terkadang rilis tidak sesuai dengan harapan. Meskipun menggunakan praktik terbaik dan melewati semua gerbang kualitas, terkadang ada masalah yang mengakibatkan penyebaran produksi menyebabkan masalah yang tidak terduga bagi pengguna. Untuk meminimalkan dan mengurangi dampak masalah ini, tim DevOps didorong untuk mengadopsi strategi paparan progresif yang menyeimbangkan paparan rilis tertentu dengan performa yang terbukti. Sebagai rilis membuktikan dirinya dalam produksi, rilis menjadi tersedia untuk tingkat audiens yang lebih luas sampai semua orang menggunakannya. Teams dapat menggunakan praktik penyebaran yang aman untuk memaksimalkan kualitas dan kecepatan rilis dalam produksi.

Mengontrol paparan pelanggan

Tim DevOps dapat menggunakan berbagai praktik untuk mengontrol paparan pembaruan kepada pelanggan. Secara historis, pengujian A/B telah menjadi pilihan populer bagi tim yang ingin melihat performa versi layanan atau antarmuka pengguna yang berbeda terhadap tujuan target. Pengujian A/B juga relatif mudah digunakan karena perubahan biasanya kecil dan sering kali hanya membandingkan rilis yang berbeda di tepi layanan yang menghadap pelanggan.

Penyebaran yang aman melalui ring

Seiring berkembangnya platform, skala infrastruktur dan kebutuhan audiens cenderung tumbuh juga. Ini menciptakan permintaan untuk model penyebaran yang menyeimbangkan risiko yang terkait dengan penyebaran baru dengan manfaat pembaruan yang dijanjikannya. Ide umumnya adalah bahwa rilis yang ditentukan harus terlebih dahulu diekspos hanya untuk sekelompok kecil pengguna dengan toleransi tertinggi untuk risiko. Kemudian, jika rilis berfungsi seperti yang diharapkan, rilis dapat diekspos ke sekelompok pengguna yang lebih luas. Jika tidak ada masalah, maka prosesnya dapat dilanjutkan melalui grup pengguna yang lebih luas, atau cincin, sampai semua orang menggunakan rilis baru. Dengan platform pengiriman berkelanjutan modern seperti Tindakan GitHub dan Azure Pipelines, membangun proses penyebaran dengan ring dapat diakses oleh tim DevOps dengan ukuran apa pun.

Gunakan bendera fitur

Fungsionalitas tertentu terkadang perlu disebarkan sebagai bagian dari rilis, tetapi awalnya tidak diekspos ke pengguna. Dalam kasus tersebut, bendera fitur menyediakan solusi di mana fungsionalitas dapat diaktifkan melalui perubahan konfigurasi berdasarkan lingkungan, cincin, atau penyebaran spesifik lainnya.

Keikutsertaan pengguna

Mirip dengan bendera fitur, keikutsertaan pengguna menyediakan cara untuk membatasi paparan. Dalam model ini, fitur tertentu diaktifkan dalam rilis, tetapi tidak diaktifkan untuk pengguna kecuali mereka secara khusus menginginkannya. Keputusan toleransi risiko dilepaskan kepada pengguna sehingga mereka dapat memutuskan seberapa cepat mereka ingin mengadopsi pembaruan tertentu.

Beberapa praktik umumnya digunakan secara bersamaan. Misalnya, tim mungkin memiliki fitur eksperimental yang ditujukan untuk kasus penggunaan yang sangat spesifik. Karena berisiko, mereka akan menyebarkannya ke ring pertama untuk dicoba oleh pengguna internal. Namun, meskipun fitur ada dalam kode, seseorang harus menetapkan bendera fitur untuk penyebaran tertentu dalam ring sehingga fitur diekspos melalui antarmuka pengguna. Bahkan kemudian, bendera fitur hanya dapat mengekspos opsi bagi pengguna untuk ikut serta menggunakan fitur baru. Siapa pun yang tidak berada di ring, pada penyebaran tersebut, atau belum ikut serta tidak akan diekspos ke fitur tersebut. Meskipun ini adalah contoh yang cukup ringkas, ini berfungsi untuk menggambarkan fleksibilitas dan kepraktisan paparan progresif.

Masalah umum yang dihadapi tim sejak dini

Saat tim bergerak menuju praktik DevOps yang lebih Tangkas, mereka mungkin mengalami masalah yang konsisten dengan orang lain yang telah bermigrasi jauh dari pengiriman monolitik tradisional. Tim yang digunakan untuk menyebarkan setiap beberapa bulan sekali memiliki pola pikir bahwa buffer untuk stabilisasi. Mereka mengharapkan bahwa setiap penyebaran akan memperkenalkan pergeseran besar dalam layanan mereka, dan bahwa akan ada masalah yang tidak terduga.

Payload terlalu besar

Layanan yang disebarkan setiap beberapa bulan biasanya diisi dengan banyak perubahan. Ini meningkatkan kemungkinan bahwa akan ada masalah segera, dan juga menyulitkan untuk memecahkan masalah tersebut karena ada begitu banyak hal baru. Dengan beralih ke pengiriman yang lebih sering, perbedaan dalam apa yang disebarkan menjadi lebih kecil, yang memungkinkan pengujian yang lebih terfokus dan penelusuran kesalahan yang lebih mudah.

Tidak ada isolasi layanan

Sistem monolitik secara tradisional diskalakan dengan meningkatkan tingkat perangkat keras tempat perangkat keras disebarkan. Namun, saat terjadi kesalahan dengan instans, hal ini menyebabkan masalah bagi semua orang. Salah satu solusi sederhana adalah menambahkan beberapa instans sehingga Anda dapat memuat pengguna keseimbangan. Namun, ini dapat memerlukan pertimbangan arsitektur yang signifikan karena banyak sistem warisan tidak dibangun untuk menjadi multi-instans. Plus, sumber daya duplikat yang signifikan mungkin perlu dialokasikan untuk fungsionalitas yang mungkin lebih baik dikonsolidasikan di tempat lain.

Saat fitur baru ditambahkan, jelajahi apakah arsitektur layanan mikro dapat membantu Anda beroperasi dan menskalakan berkat isolasi layanan yang lebih baik.

Langkah manual menyebabkan kesalahan

Ketika tim hanya menyebarkan beberapa kali per tahun, mengotomatiskan pengiriman mungkin tidak sepadan dengan investasi. Akibatnya, banyak proses penyebaran dikelola secara manual. Ini memerlukan banyak waktu dan upaya, dan rentan terhadap kesalahan manusia. Cukup mengotomatiskan tugas build dan penyebaran yang paling umum dapat berjalan jauh untuk mengurangi waktu yang hilang dan kesalahan yang tidak diberlakukan.

Tim juga dapat menggunakan infrastruktur sebagai kode agar kontrol atas lingkungan penyebaran semakin baik. Ini menghapus kebutuhan akan permintaan ke tim operasi untuk membuat perubahan manual karena fitur atau dependensi baru diperkenalkan ke berbagai lingkungan penyebaran.

Hanya Ops yang dapat melakukan penyebaran

Beberapa organisasi memiliki kebijakan yang mengharuskan semua penyebaran dimulai dan dikelola oleh staf operasi. Meskipun mungkin ada alasan bagus untuk itu di masa lalu, proses Agile DevOps sangat menguntungkan ketika tim pengembangan dapat memulai dan mengontrol penyebaran. Platform pengiriman berkelanjutan modern menawarkan kontrol terperinci atas siapa yang dapat memulai penyebaran mana, dan siapa yang dapat mengakses log status dan informasi diagnostik lainnya, memastikan orang yang tepat memiliki informasi yang tepat secepat mungkin.

Penyebaran buruk dilanjutkan dan tidak dapat dikembalikan

Terkadang penyebaran salah dan tim perlu mengatasinya. Namun, saat proses manual dan akses ke informasi lambat dan terbatas, mungkin sulit untuk kembali ke penyebaran kerja sebelumnya. Untungnya, ada berbagai alat dan praktik untuk mengurangi risiko penyebaran yang gagal.

Prinsip inti

Tim ingin mengadopsi praktik penyebaran yang aman harus menetapkan beberapa prinsip inti untuk mendasari upaya tersebut.

Konsisten

Alat yang sama yang digunakan untuk menyebarkan dalam produksi harus digunakan dalam lingkungan pengembangan dan pengujian. Jika ada masalah, seperti yang sering muncul dari versi dependensi atau alat baru, mereka harus ditangkap dengan baik sebelum kode hampir dirilis ke produksi.

Peduli dengan sinyal berkualitas

Terlalu banyak tim jatuh ke dalam perangkap umum yang tidak benar-benar peduli dengan sinyal kualitas. Seiring waktu, mereka mungkin menemukan bahwa mereka menulis pengujian atau mengambil tugas berkualitas hanya untuk mengubah peringatan kuning menjadi persetujuan hijau. Sinyal berkualitas sangat penting karena mewakili denyut nadi proyek. Sinyal berkualitas yang digunakan untuk menyetujui penyebaran harus dilacak terus-menerus setiap hari.

Penyebaran harus memerlukan waktu henti nol

Meskipun tidak penting bagi setiap layanan untuk selalu tersedia, tim harus mendekati tahap pengiriman dan operasi DevOps mereka dengan pola pikir yang mereka dapat dan harus menyebarkan versi baru tanpa harus menurunkannya kapan saja. Infrastruktur modern dan alat alur cukup canggih sekarang di mana memungkinkan bagi hampir semua tim untuk menargetkan waktu aktif 100%.

Penyebaran harus dilakukan selama jam kerja

Jika tim bekerja dengan pola pikir bahwa penyebaran memerlukan waktu henti nol, maka itu tidak terlalu penting saat penyebaran didorong. Selanjutnya, menjadi menguntungkan untuk mendorong penyebaran selama jam kerja, terutama di awal hari dan di awal minggu. Jika terjadi kesalahan, itu harus dilacak cukup awal untuk mengontrol radius ledakan. Plus, semua orang sudah bekerja dan fokus untuk memperbaiki masalah.

Penyebaran berbasis ring

Teams dengan praktik rilis DevOps yang matang berada dalam posisi untuk mengambil penyebaran berbasis ring. Dalam model ini, fitur baru pertama kali diluncurkan kepada pelanggan yang bersedia menerima risiko paling besar. Karena penyebaran terbukti, audiens meluas untuk menyertakan lebih banyak pengguna sampai semua orang menggunakannya.

Contoh model ring

Model penyebaran ring yang khas dirancang untuk menemukan masalah sedini mungkin melalui segmentasi pengguna dan infrastruktur yang cermat. Contoh berikut menunjukkan bagaimana cincin digunakan oleh tim utama di Microsoft.

Izinkan waktu bake

Istilah waktu kue mengacu pada jumlah waktu penyebaran diizinkan untuk dijalankan sebelum memperluas ke cincin berikutnya. Beberapa masalah mungkin memakan waktu berjam-jam atau lebih lama untuk mulai menunjukkan gejala, sehingga rilis harus digunakan untuk jumlah waktu yang sesuai sebelum dianggap siap.

Secara umum, hari 24 jam harus cukup waktu untuk sebagian besar skenario untuk mengekspos bug laten. Namun, periode ini harus mencakup periode penggunaan puncak, membutuhkan hari kerja penuh, untuk layanan yang memuncak selama jam kerja.

Percepat perbaikan

Insiden situs langsung (LSI) terjadi ketika bug memiliki dampak serius dalam produksi. LSI mengharuskan pembuatan perbaikan, yang merupakan pembaruan di luar band yang dirancang untuk mengatasi masalah prioritas tinggi.

Jika bug adalah Sev 0, jenis bug yang paling parah, perbaikan dapat disebarkan langsung ke unit skala yang terkena dampak secepat mungkin secara bertanggung jawab. Meskipun sangat penting bahwa perbaikan tidak memperburuk keadaan, bug dari tingkat keparahan ini dianggap sangat mengganggu sehingga harus segera ditangani.

Bug yang diberi peringkat Sev 1 harus disebarkan melalui ring 0, tetapi kemudian dapat disebarkan ke unit skala yang terpengaruh segera setelah disetujui.

Perbaikan untuk bug dengan tingkat keparahan yang lebih rendah harus disebarkan melalui semua ring seperti yang direncanakan.

Poin penting

Setiap tim ingin memberikan pembaruan dengan cepat dan dengan kualitas setinggi mungkin. Dengan praktik yang tepat, pengiriman dapat menjadi bagian yang produktif dan tidak menyakitkan dari siklus DevOps.

• Sebarkan sering.
• Tetap hijau di seluruh sprint.
• Gunakan alat penyebaran yang konsisten dalam pengembangan, pengujian, dan produksi.
• Gunakan platform pengiriman berkelanjutan yang memungkinkan otomatisasi dan otorisasi.
• Ikuti praktik penyebaran yang aman.

Langkah berikutnya

Pelajari bagaimana bendera fitur membantu mengontrol paparan fitur baru kepada pengguna.