Cara apa yang ada untuk memisahkan penyebaran dari rilis?

Salah satu metode penyebaran berkelanjutan adalah untuk memisahkan penyebaran dari rilis, yaitu menyebarkan pembaruan tanpa mengaktifkan perubahan dengan segera.

Saya tahu bahwa fitur-toggle dapat digunakan untuk ini, tapi saya ingin tahu apakah ada teknik lain untuk "non-fitur".

Misalnya, apakah Anda membuat fitur beralih untuk perbaikan bug? Mungkin tidak dan orang bisa berpendapat bahwa perbaikan bug harus dikerahkan sesegera mungkin, karena itu hanya bisa menjadi lebih baik. Dan setelah perbaikan bug telah dirilis, saya yakin tidak ingin mematikannya lagi. Tetapi apakah ini yang terjadi? Mungkin ini adalah perubahan berisiko yang ingin Anda lepaskan dengan cara yang terkontrol. Dan jika ada yang efek samping tak terduga, ada baiknya untuk dapat gulung kembali. Jadi, fitur flags untuk setiap perubahan?

Dan bagaimana dengan perubahan visual? Misalnya, dapatkah Anda menerapkan sesuatu seperti flag fitur di CSS? Apakah itu masuk akal?

Untuk perangkat lunak dalam kategori aplikasi web, tergantung pada penyedia infra / hosting Anda, decoupling seperti itu mungkin untuk mengalihkan lalu lintas masuk (atau membaginya antara) berbagai versi yang digunakan dari sw, secara praktis mencakup setiap perubahan yang Anda sebutkan: perbaikan bug, visual , dll.

Dukungan seperti itu biasanya tidak memerlukan fitur toggle. Dan itu mungkin berlaku terlepas dari aplikasi monolitik atau terbelah dalam layanan microser.

Misalnya penawaran Google App Engine Paas memiliki dukungan untuk pemisahan lalu lintas dan migrasi.

Dari Membagi Lalu Lintas :

Anda dapat menggunakan pemisahan lalu lintas untuk menentukan persentase distribusi lalu lintas di dua atau lebih versi dalam layanan. Memisahkan lalu lintas memungkinkan Anda untuk melakukan pengujian A / B antara versi Anda dan memberikan kontrol atas kecepatan saat meluncurkan fitur.

Dari Migrasi Lalu Lintas :

Migrasi lalu lintas mengalihkan perutean permintaan antara versi dalam layanan aplikasi Anda, memindahkan lalu lintas dari satu versi atau lebih ke satu versi baru.

Sementara dengan monolith, Anda mungkin dibatasi untuk sakelar, dengan arsitektur layanan mikro, Anda dapat membagi setiap kumpulan penyebaran node yang menyediakan layanan (mis. Pod). Anda kemudian mengaktifkan penyebaran produk yang baru saja diubah dalam kumpulan kelompok, dan memonitornya dengan cermat; Anda bahkan dapat memilih jumlah kumpulan mana yang akan digunakan untuk mengubah, misalnya, mengaktifkan perubahan untuk 15% dari lalu lintas. Anda mungkin menemukan fitur yang disebut "pembaruan bergulir" dalam literatur.