Matikan fitur: Tampilan, Manfaat, dan Bekerja dengannya dalam .NET

Peralihan fungsionalitas adalah alat yang memungkinkan Anda untuk beralih dari fungsi lama ke yang baru tanpa membangun kembali aplikasi dan melepaskannya lagi. Ini diimplementasikan dengan menambahkan operator kondisional ( if ) ke kode, yang memungkinkan untuk mengontrol perilaku program dengan hanya mengubah nilai yang diinginkan dalam file konfigurasi atau database. Jika Anda pernah mengedit pengaturan dalam file-in, maka Anda sudah familiar dengan teknologi ini.

Menggali lebih dalam, Anda dapat menemukan sejumlah besar opsi berbeda untuk sakelar dan fitur baru yang disediakannya. Ini menimbulkan banyak pertanyaan. Di mana menempatkan konfigurasi? Tetapi bagaimana jika itu menjadi tidak tersedia? Mungkin Anda bisa menulis kerangka kerja sederhana untuk bekerja dengan sakelar sendiri? Mungkin lebih baik mengambil solusi yang sudah jadi? Apakah ini cocok untuk monolit dan layanan mikro?

Materi ini berisi informasi dasar tentang sakelar fungsionalitas dalam konteks pengembangan pada platform .NET. Bagian pertama berisi informasi umum tentang sakelar; mereka cukup independen dari implementasi spesifik dan mungkin berguna bagi para profesional yang bekerja dengan berbagai platform. Bagian kedua membahas alat modern spesifik yang memfasilitasi penggunaan sakelar saat berkembang untuk .NET.

Saya mencoba menulis artikel yang akan membantu Anda memutuskan apakah akan menerapkan sakelar fungsionalitas dalam kasus spesifik Anda, dan jika perlu, caranya. Di departemen kami, saklar sejauh ini hanya digunakan untuk memecahkan masalah tertentu. Sebagai contoh, aplikasi kita seringkali perlu meminta informasi hukum dan akuntansi dari katalog, yang dapat disajikan dalam dua bentuk: katalog lengkap jarak jauh dan sebagian salinan lokalnya. Dalam pengaturan aplikasi, pengguna dapat memilih jenis direktori yang harus digunakan aplikasi saat ini. Rencana tersebut termasuk pengenalan sakelar sebagai infrastruktur umum untuk keseluruhan proyek. Berdasarkan itu, proses yang mirip dengan yang dijelaskan di atas akan dibangun.

Ikhtisar Alih Fungsi

Apa ini

Secara sederhana, arti dari sakelar adalah sebagai berikut. Kontraktor maju melalui kode kami, mewakili logika area subjek, dan menemukan pernyataan bersyarat. Dalam pernyataan ini, kontraktor bertanya apakah beberapa kode kondisional perlu dijalankan dari beberapa registri yang tahu kapan dan dalam keadaan apa fungsi yang diinginkan harus berfungsi.


Akibatnya, eksekutor berjalan di sepanjang satu cabang atau sepanjang yang lain, dan dalam kasus yang merosot, cabang lainnya kosong. Dalam kasus paling sederhana, saklar mengambil salah satu dari dua nilai ("hidup" dan "mati") di bawah kendali orang yang bertanggung jawab yang mengelola registri. Dan Anda dapat menemukan sesuatu yang lebih rumit, misalnya, menyertakan fungsionalitas hanya untuk pengguna tertentu atau untuk pengguna dari negara tertentu, atau pada waktu tertentu.

Registri fungsionalitas dapat mengambil berbagai bentuk. Intinya adalah ketika Anda dapat mengelola registri ini tanpa menghentikan aplikasi atau memindahkannya kembali. Misalnya, sakelar dapat disimpan dalam file, dalam basis data, atau memiliki layanan jaringan terpisah dengan sakelar. Di bawah ini pengoperasian sakelar dipertimbangkan lebih terinci.

Apakah ini relevan?

Dalam artikelnya, pembuat featureflag.tech mengklaim bahwa sakelar menjadi praktik standar dalam pengembangan perangkat lunak. Ada semakin banyak bahan tentang switch: artikel teoritis, cerita tentang praktik penerapan switch, laporan di konferensi. Saya telah menyertakan tautan ke materi yang paling menarik dalam teks artikel ini; Semua tautan dikumpulkan di bagian "Kesimpulan" .

Saya akan mengatakan bahwa pertumbuhan popularitas switch difasilitasi oleh stabilisasi dan standardisasi di beberapa bidang teknologi informasi. Dalam "perusahaan berdarah" muncul semakin banyak pulau stabilitas. Peningkatan jumlah metrik dalam pengembangan, otomatisasi perakitan, inspeksi dan pengiriman aplikasi mengarah pada fakta bahwa proses pengembangan menjadi lebih transparan dan mudah dikelola. Akibatnya, persyaratan untuk tingkat baru mulai disajikan untuk pembuatan perangkat lunak. Salah satu persyaratan ini adalah keinginan untuk menyebar dalam waktu saat-saat publikasi aplikasi dan dimasukkannya fungsi baru, yang diimplementasikan oleh switch. Kemampuan industri telah matang untuk memenuhi permintaan industri ini.

Adapun alat yang membantu untuk bekerja dengan sakelar, ada sangat, sangat banyak dari mereka, dan untuk berbagai platform. Mungkin, penampilan sejumlah besar alat dijelaskan oleh kesederhanaan yang Anda dapat menerapkan kemampuan dasar switch. Tetapi penambahan roti yang lebih kompleks dan "enak" mungkin memerlukan biaya tenaga kerja yang signifikan, sehingga banyak proyek open source yang mengimplementasikan sakelar fungsionalitas berhenti berkembang dan didukung. Namun demikian, sejumlah besar proyek, baik yang berbayar maupun gratis, tetap bertahan. Yang paling menarik dari mereka (dari sudut pandang .NET) dijelaskan di bagian kedua artikel .

Sedikit lagi

Artikel ini memiliki diagram yang baik menggambarkan operasi switch; Saya mengundang Anda untuk membiasakan diri dengannya.


Kami mulai mempertimbangkan sirkuit dengan kode. Biarkan dalam contoh kami fungsi baru - memeriksa kebenaran mengisi dokumen. Kami memastikan bahwa dokumen diperiksa hanya jika fungsi ini diaktifkan. Mari kita buat titik perpindahan:

 var document = GetDocument(); if (feature.IsEnabled("Feature #123. Document validation")) { Validate(document); } 

Dalam hal ini, feature adalah referensi ke infrastruktur yang membantu aplikasi kita berkomunikasi dengan router dan registry fungsionalitas. Menggunakan infrastruktur ini, kami mencari tahu apakah perlu untuk memeriksa dokumen, dan jika demikian, maka periksa.

Router menggunakan informasi yang tersedia untuknya: nama fungsionalitas yang kami berikan sebagai argumen, dan apa yang dapat kami ekstrak dari kelas statis yang diketahui untuk menentukan apakah fungsionalitas yang diminta harus berfungsi dalam kasus ini. Router mengetahui bagaimana switch di registri dikonfigurasikan. Jika registri tidak tersedia, Anda harus menggunakan data yang sebelumnya di-cache, atau menggunakan beberapa strategi lain untuk kasus ini. Anda juga dapat membayangkan router yang secara eksplisit menerima informasi tambahan (konteks) melalui argumen metode yang membantunya memutuskan apakah akan mengaktifkan fungsionalitas saat ini.

Personel yang bertanggung jawab mengonfigurasi sakelar dengan cara yang dipilih. Dalam opsi yang paling menyenangkan, mereka pergi ke situs yang mewakili registry switch, dan klik pada switch yang dipilih dengan mouse.

Jadi, dalam artefak, sistem sakelar terdiri dari dua bagian. Di satu sisi, ini adalah infrastruktur bagi seorang programmer untuk mengetahui apakah fungsionalitas harus bekerja dalam kasus ini dan eksekusi langsung di sepanjang cabang kode yang sesuai. Di sisi lain, ini adalah mekanisme yang memungkinkan karyawan yang bertanggung jawab untuk memilih fungsionalitas mana yang akan diaktifkan dan yang dimatikan. Dalam kasus yang merosot (ketika registri dijahit ke dalam kode, lihat di bawah), kedua artefak dapat bertepatan, dan programmer dapat mengontrol fungsi hidup dan mati.

Kemungkinan persyaratan sistem sakelar

Seperti yang Anda lihat, sistem sakelar bisa sangat rumit. Kami mencantumkan persyaratan dasar yang dapat dikenakan pada sistem tersebut.

1. Ketergantungan fungsi hidup dan mati parameter yang berbeda. Contoh parameter: pengguna (peran, pengidentifikasi, lokasi geografis), waktu (siang atau gelap, bekerja atau hari kerja, periode waktu tertentu), lingkungan (untuk pengembangan, pengujian, operasi industri).
2. Kumpulan statistik penggunaan saat menganalisis proses domain: pengguna mana dalam kondisi apa yang melihat atau tidak melihat fungsionalitas, berapa kali mereka menggunakan fungsionalitas baru.
3. Audit tentang apa yang terjadi dengan sakelar itu sendiri: siapa yang menekannya, kapan, apa yang berubah.
4. Memberikan pilihan yang fleksibel antara fungsi registri lokal dan jarak jauh atau beberapa strategi jika registri jarak jauh tidak tersedia.
5. Mengkonfigurasi akses ke sistem switch untuk berbagai kategori karyawan baik di pelanggan dan kontraktor: spesialis teknis, spesialis di bidang subjek, serta pengguna aplikasi itu sendiri.

Tentu saja, berusaha untuk memenuhi semua persyaratan ini tidak perlu. Dalam banyak kasus, beberapa persyaratan, sebaliknya, mungkin tidak diinginkan. Semakin banyak persyaratan yang harus Anda patuhi, yang jelas lebih memberatkan adalah pengembangan sistem sakelar Anda sendiri. Ini berarti bahwa pada titik tertentu setelah pengenalan sakelar, dukungan sistem Anda sendiri menjadi tidak menguntungkan dan sekarang saatnya mengambil solusi yang sudah jadi.

Pohon teknologi

Kami merangkum informasi yang dipertimbangkan tentang sakelar fungsi, menggunakan metafora pohon teknologi dari video game. Mari kita bayangkan switch sebagai teknologi yang memungkinkan perusahaan untuk meluncurkan fungsionalitas baru tanpa terikat dengan momen-momen perakitan dan penyebaran aplikasi. Teknologi ini memiliki biaya yang diketahui (biaya pemeliharaan siklus hidup sakelar dan registri) dan prasyarat untuk implementasi: metodologi pengembangan yang fleksibel ditambah integrasi yang berkelanjutan. Tentu saja, integrasi terus-menerus bukanlah prasyarat, tetapi membuat sakelar jauh lebih efisien dan memungkinkan pengiriman aplikasi secara terus menerus. Selain itu, "penelitian" switch "membuka" teknologi lain - pengujian A / B dan rilis kenari. Mereka akan dibahas di bawah ini.

Di mana registri fungsi dapat ditemukan

Pertimbangkan beberapa opsi untuk menempatkan registri fungsionalitas, menempatkannya dalam peningkatan kompleksitas implementasi.

1. Jahit konfigurasi langsung ke kode, misalnya, komentar kode yang tidak perlu dan batalkan komentar pada kode yang diperlukan atau gunakan arahan kompilasi bersyarat. Jelas, opsi ini membunuh esensi dari pengenalan switch, karena dengan itu Anda perlu mengkompilasi ulang dan menggunakan aplikasi untuk melihat fungsionalitas baru. Dua kesulitan juga harus diperhatikan. Pertama, dengan pendekatan ini, seorang karyawan yang menyertakan fungsionalitas akan memerlukan keterampilan teknis tambahan: mengedit kode sumber dan kemampuan untuk bekerja dengan sistem kontrol versi (SLE). Tuhan tahu keterampilan apa, tentu saja, tetapi kemungkinan besar, programmer itu sendiri harus memasukkan fungsionalitas. Kedua, fungsi akan sama pada semua node di mana versi aplikasi ini diterbitkan - untuk memilih antara fungsi lama dan baru, Anda akan memerlukan penyeimbang dan beberapa node dengan aplikasi.
2. Tempatkan konfigurasi di lingkungan aplikasi, misalnya, dalam variabel lingkungan. Opsi ini tampaknya sedikit boros, karena penuh dengan tampilan ketergantungan yang berlebihan pada runtime atau pada sistem operasi.
3. Gunakan file konfigurasi, yang merupakan tempat yang cukup standar untuk menyimpan pengaturan aplikasi. Kerugian dari opsi ini adalah perlunya memelihara file konfigurasi secara terpisah di sebelah setiap instance aplikasi. Kelemahan ini melekat pada versi sebelumnya.
4. Menyimpan tabel dalam database yang menjelaskan sakelar untuk fungsionalitas. Mesin virtual aplikasi akan mengetuk basis data ini untuk melihat apakah fungsionalitas yang menarik minat mereka berfungsi. Dalam opsi ini, registri terpusat (tidak seperti versi sebelumnya), tetapi memungkinkan untuk memasukkan fungsionalitas secara terpisah untuk setiap node, jika ini didukung oleh infrastruktur switch yang dipilih.
5. Naikkan layanan jaringan yang akan diakses oleh instance aplikasi melalui protokol jaringan yang dipilih. Jika dalam versi sebelumnya itu berarti bahwa switch kemungkinan besar akan disimpan bersama dengan entitas dari area subjek, dan oleh karena itu biaya polling switch akan dapat diprediksi, maka di sini kita akan memiliki akses tambahan melalui jaringan. Biaya penanganan tambahan dan kemungkinan penolakan layanan adalah kelemahan serius dari opsi ini, tetapi, tentu saja, caching tidak dilarang. Dan untuk kegagalan, Anda harus memberikan perilaku default.

Rekomendasi

Mengenai penggunaan sakelar, rekomendasi umum berikut dapat dibuat.

Titik perpindahan dan logika tidak harus bersama . Dalam contoh paling sederhana, setelah pernyataan kondisional, di mana kami menginterogasi keadaan saklar tertentu, kode segera mengimplementasikan fungsionalitas yang disertakan. Ini sangat tidak nyaman, karena menambah ketergantungan yang berlebih pada logika: pengetahuan tentang infrastruktur sakelar dan nama fungsi tertentu dari registri. Dalam praktiknya, ini mempersulit proses pengujian dan pelepasan sakelar saat tidak diperlukan.

Atur titik switching lebih tinggi . Pengembangan paragraf sebelumnya. Poin-poin di mana infrastruktur switch diakses harus dikecualikan dari logika area subjek ke peluang terakhir, yaitu, untuk "mendorong" mereka lebih dekat ke tempat permintaan. Dengan demikian, kami mengurangi ketergantungan masing-masing modul pada sakelar, menyederhanakan proses dukungan dan pengujiannya.

Gunakan strategi alih-alih pernyataan bersyarat . Jika switch akan hidup untuk waktu yang lama, maka operator kondisional dapat ditingkatkan menjadi strategi dan secara eksplisit mengisolasi logika switchable menjadi sesuatu yang diikuti dan diuji secara terpisah.

Jangan kelompokkan sakelar . Anda seharusnya tidak membentuk dependensi di antara sakelar, mengelompokkannya dan merakitnya dalam hierarki. Ini akan membuatnya lebih mudah untuk mempertahankan kode dengan fungsionalitas baru dan siklus hidup sakelar itu sendiri.

Konsolidasi titik sakelar untuk satu fungsi . Mungkin ternyata perilaku beberapa blok program sekaligus tergantung pada sakelar yang sama. Jika pengembangannya tidak terkoordinasi dengan baik, titik-titik perpindahan dapat digandakan di tempat yang berbeda, dan ini mengarah pada pengujian dan dukungan yang lebih mahal. Jika Anda disiplin untuk mencoba "mendorong" titik-titik peralihan ke pintu masuk ke aplikasi, maka rekomendasi ini - jangan hamburkan titik di seluruh sistem - biasanya dilakukan secara otomatis.

Kategori utama sakelar

Pertimbangkan klasifikasi saklar yang diberikan dalam artikel ini . Ini didasarkan pada berapa lama saklar "hidup" dan seberapa sering keadaannya berubah. Penugasan sakelar ke kelas tertentu membantu menentukan cara menggunakan sakelar dalam kode dan cara menyimpan status sakelar.

Lepaskan Sakelar

Ini adalah tampilan utama sakelar. Mereka memungkinkan Anda untuk memusatkan pengembangan di satu cabang utama, yang, terlebih lagi, secara rutin diluncurkan ke dalam operasi komersial. Alih-alih mengembangkan di cabang terpisah dan menyuntikkannya ke cabang utama untuk merilis versi yang diinginkan, kami memperkenalkan titik switching dalam kode, yang menyembunyikan fungsi yang belum siap dari pengguna. Saat siap, sakelar meluncurkan fungsionalitas baru.

Switch semacam itu hidup selama beberapa hari atau minggu - sementara pengembangan dan implementasi fungsi baru sedang berlangsung. Ketika fungsionalitas telah diuji dan dianggap cocok, sakelar dan titik sakelar dalam kode dapat dihapus. Keadaan saklar biasanya berubah baik ketika versi baru dirilis, atau ketika konfigurasi aplikasi berubah. Dimungkinkan untuk menyimpan sakelar seperti itu di file konfigurasi. Ada kemungkinan besar bahwa titik sakelar untuk fungsionalitas baru akan menjadi satu-satunya; masuk akal untuk tidak menggali dan menempatkannya dalam bentuk pernyataan kondisional konvensional.

Saklar Eksperimen

Untuk menjalankan fungsi baru, sakelar digunakan yang hidup dari beberapa hari hingga beberapa bulan. Selama percobaan, Anda dapat memantau bagaimana pengguna melihat perubahan dan bagaimana perilaku mereka berubah. Sangat diharapkan bahwa keadaan saklar dapat berubah sangat dinamis dengan setiap permintaan. Beberapa penyimpanan terpusat, seperti basis data atau layanan jaringan, lebih mungkin cocok di sini. Jika percobaan sesuai dengan sejumlah masalah yang dapat diramalkan, maka titik peralihan juga dapat dikeluarkan dalam bentuk pernyataan bersyarat.

Sakelar teknis Sakelar

teknis membantu mengelola bagian infrastruktur suatu aplikasi yang memengaruhi kinerja keseluruhannya. Mereka bisa berguna ketika kita meluncurkan pembaruan yang dampak kinerjanya sulit untuk dievaluasi. Dalam hal ini, alangkah baiknya jika memiliki "saklar" yang langsung menonaktifkan fungsionalitas baru jika ternyata penggunaannya menimbulkan konsekuensi bencana.

Kemungkinan besar, sakelar semacam itu akan hidup selama beberapa minggu atau lebih lama, dan akan berubah status saat konfigurasi aplikasi berubah atau lebih sering. Kekritisan fungsi yang diimplementasikan switch ini menunjukkan bahwa mereka perlu menggunakan layanan jaringan atau setidaknya database. Anda harus mulai memastikan bahwa dalam kode titik-titik switching untuk fungsi yang sama tidak tersebar di tempat yang berbeda.

Switch untuk kontrol akses

Kesempatan lain yang jelas untuk menggunakan switch adalah untuk menyediakan akses ke fungsionalitas baru hanya untuk beberapa pengguna. Ini mungkin diperlukan baik untuk rilis kenari (ketika fungsionalitas baru secara bertahap mencakup semakin banyak pengguna), dan untuk membuat bagian pribadi di mana hanya pengguna istimewa yang memiliki akses.

Tampaknya switch semacam itu hidup cukup lama (mungkin selama aplikasi itu sendiri) dan dapat mengubah status dengan setiap permintaan baru. Layanan jaringan untuk menyimpan sakelar juga cocok di sini. Disarankan untuk menggunakan semacam mekanisme terpusat untuk memilih antara fungsi lama dan baru dan tidak menyebarkan pernyataan bersyarat di seluruh kode.

,

Pengenalan switch fungsionalitas tidak hanya memiliki keuntungan yang jelas, untuk itu semuanya biasanya dimulai (keragaman dalam waktu penerbitan aplikasi dan beralih pada fungsionalitas baru, mengurangi jumlah cabang dalam mata uang keras), tetapi juga dapat menyederhanakan beberapa proses samping. Kami daftar mereka dan kemudian mempertimbangkan beberapa lebih detail.

Pengujian A / B. Perbandingan perilaku pengguna menggunakan versi lama dan baru.

Masalah kenari. Peningkatan bertahap dalam jumlah pengguna dengan akses ke fungsionalitas baru.

Rilis biru-hijau. Kirim permintaan menggunakan balancer ke server dengan versi lama atau server dengan versi baru.

Direncanakan fungsi ekstrem.Dimasukkannya fungsionalitas untuk waktu yang singkat, misalnya selama promosi.

Dimasukkannya fungsi secara simultan di beberapa tempat. Dimasukkannya fungsionalitas pada saat yang sama baik di situs dan di aplikasi seluler. Atau dimasukkannya fungsi secara bersamaan dalam modul yang berbeda dari aplikasi yang sama.

Perubahan infrastruktur besar. Misalnya, transisi ke cara lain menyimpan data.

Menguji hal-hal baru oleh pengguna. Memberi pengguna kemampuan untuk menghidupkan dan mematikan fungsionalitas baru, menyesuaikan aplikasi untuk diri mereka sendiri.

Pengujian A / B

Mari kita lihat sebentar apa itu pengujian A / B. Saat menyiapkan pengujian A / B, beberapa sifat terukur dari sistem informasi atau perilaku pengguna dirumuskan. Contoh properti ini: 1) durasi proses tertentu di area subjek, 2) jumlah relatif pengguna yang telah mengunjungi halaman tertentu, 3) jumlah sumber daya yang digunakan aplikasi. Selain itu, asumsi dibuat bagaimana nilai properti ini akan berubah ketika fungsionalitas baru disertakan. Akankah pengguna mendapatkan respons yang lebih cepat? Apakah mereka akan membeli lebih banyak? Apakah aplikasi akan makan lebih sedikit?

Kemudian, selama pengujian A / B, untuk satu kelompok, fungsi baru dihidupkan, dan untuk yang lain, itu tetap tidak aktif. Asumsi yang dibuat selama persiapan diperiksa, dan berdasarkan hasil disimpulkan apakah fungsionalitas baru memberikan sesuatu yang baik dan tidak mengarah pada sesuatu yang buruk. Terkadang pengguna dibagi menjadi tiga kelompok, di mana dua di antaranya fungsinya tetap tua. Jika hasil dari dua kelompok kontrol sangat berbeda, maka seluruh tes mengandung beberapa jenis kesalahan, membuat kesimpulan berdasarkan tes ini tidak dapat diandalkan.

Sakelar fungsi memudahkan untuk membagi pengguna menjadi beberapa kelompok dan mengelolanya. Untuk setiap grup, Anda dapat mengaktifkan dan menonaktifkan fungsionalitas baru tanpa menunggu rilis aplikasi berikutnya. Ini mengurangi waktu yang diperlukan untuk memverifikasi asumsi dan menyelesaikan seluruh siklus uji A / B. Banyak perusahaan berusaha untuk membuat verifikasi dari beberapa asumsi per minggu.

Anda dapat mempelajari lebih lanjut tentang metode ini dari artikel ini , di sini dan di sini di "Habré", dan itu pasti patut dilihat pada laporan "Fitur Toggles, atau Bagaimana cara menggulung fitur tanpa rilis" , yang mengungkapkan beberapa seluk beluk yang menarik dari pengujian A / B dengan sakelar fungsionalitas.

Masalah

kenari dan biru-hijau Apa hubungannya kenari dengan itu? Burung kenari digunakan dalam industri pertambangan: para penambang membawa burung kenari ke dalam kandang ketika mereka turun ke tambang, di mana diduga terdapat gas-gas peledak konsentrasi tinggi. Burung kenari sangat menyukai udara bersih dan jauh lebih awal daripada orang-orang mulai merasakan kotoran berbahaya dan berbahaya di dalamnya. Jika kenari berhenti bernyanyi, mati, atau mati, maka orang perlu segera mengungsi sampai meledak. Di sini sini Anda dapat membaca lebih lanjut tentang ini (dalam bahasa Inggris).

Dari sini, seperti yang saya mengerti, ungkapan "kesaksian kenari" berasal dari. Jika Anda tinggal di negara bagian yang menerapkan kebijakan domestik yang represif (yaitu, di negara mana pun), suatu hari Anda mungkin menemukan bahwa Anda telah diperintahkan tidak hanya untuk mentransfer data pribadi pengguna Anda ke departemen yang berwenang, tetapi juga tidak memberi tahu siapa pun bahwa Anda mereka diserahkan, bukan karena Anda menerima pesanan seperti itu. Tentu saja, Anda tidak akan bisa keluar, tetapi dalam beberapa kasus Anda dapat secara teratur mengirim pesan semacam ini kepada pengguna Anda: "Bulan lalu kami tidak menerima pesanan untuk mengungkapkan data pribadi Anda." Begitulah cara Anda berkicau, berkicau seperti burung kenari, dan ketika Anda mendapatkan pesanan untuk memberikan data pribadi, Anda tutup mulut. Dengan demikian, Anda mematuhi persyaratan pihak berwenang, dan memberikan alasan kepada pengguna Anda untuk waspada.

Dan ada masalah kenari. Di sini metafora bekerja seperti ini: ketika sebagian kecil pengguna sakit, kami segera "mengungsi" - kami mematikan fungsi baru yang menyebabkan pengguna menjadi sakit dan tidak membiarkannya menjangkau semua pengguna (jangan biarkan "brengsek"). Untuk melakukan ini, Anda harus dapat memperluas fungsionalitas baru ke grup yang berbeda. Di sini Anda dapat melakukannya tanpa sakelar. Sebagai contoh, kami memiliki penyeimbang dan dua simpul di mana ia mengalihkan permintaan. Pada satu node, kami telah menggunakan versi stabil, dan pada yang kedua, versi eksperimental yang mengandung fungsionalitas baru. Secara default, semua permintaan dikirim ke node dengan versi stabil, dan dengan bantuan balancer kami mulai mengirim beberapa permintaan ke node dengan versi eksperimental.

Tetapi dengan sakelar, Anda dapat mencapai lebih banyak fleksibilitas dalam hal fungsionalitas baru meluas ke pengguna. Di sakelar, Anda dapat menggabungkan berbagai parameter permintaan yang diterima dan memberikan antarmuka grafis yang nyaman bagi karyawan yang bertanggung jawab untuk mengelola masalah kenari. Secara umum, prosesnya tetap sama: kami menyertakan fungsionalitas baru untuk sekelompok kecil pengguna, misalnya, untuk 1%. Setelah itu, kami memantau keadaan aplikasi, bagaimana pengguna yang bekerja dengan fungsionalitas baru berperilaku, dan membuat perkiraan tentang apa yang akan terjadi ketika kami memperluasnya ke jumlah pengguna yang lebih besar. Secara bertahap merangkul semakin banyak pengguna dengan fungsi baru, kami dapat menguji dan menyesuaikan hipotesis kami. Jika kita perhatikan tren negatif,maka fungsi baru dapat dengan mudah dinonaktifkan.

Selama rilis biru-hijau, dua server digunakan, sementara disebut biru dan hijau. Kami berasumsi bahwa sebelum rilis, penyeimbang mengirim semua permintaan ke server hijau. Selama rilis, versi baru aplikasi digunakan pada server biru, tempat penyeimbang juga mulai mengirim permintaan. Jika ternyata versi baru aplikasi berisi kesalahan, maka kami beralih kembali ke server hijau.

Versi dasar dari rilis biru-hijau menunjukkan bahwa pengguna bekerja dengan semua fungsi baru yang termasuk dalam versi baru, atau tidak bekerja dengan apa pun. Dan dengan penggunaan sakelar, menjadi mungkin selama rilis untuk mengirim permintaan ke server biru dengan versi baru, yang sakelar semua fungsi baru dimatikan. Setelah itu, Anda dapat secara bertahap menggabungkan fungsi baru di beberapa bagian.

Anda dapat melihat bahwa sakelar fungsi memungkinkan Anda menggabungkan manfaat rilis kenari dan biru-hijau. Biasanya, selama rilis biru-hijau, ada dua node yang dipisahkan dengan jelas dengan versi lama dan baru dari aplikasi, dan dengan bantuan penyeimbang kami mengarahkan semua permintaan sekaligus ke salah satu node atau yang lain. Dan dengan sakelar, kita dapat mengarahkan permintaan ke simpul dengan versi baru, tetapi dengan fungsi baru dimatikan, dan kemudian secara bertahap menyalakannya, seperti saat rilis kenari.

Sedikit lebih detail tentang masalah kenari - dalam artikel yang sesuai di situs web Fowler atau "Habré", misalnya di sini . Tentang rilis biru-hijau - dalam artikel ulasan. Dan penggunaan sakelar fungsi dalam rilis biru-hijau dapat ditemukan di sini .

Mengubah cara data disimpan.

Untuk waktu yang lama, ketika mempelajari teknik pemrograman seperti abstraksi dan pengembangan dari antarmuka, saya sering menemukan rekomendasi berikut: cobalah untuk mencegah program Anda dari terikat pada metode penyimpanan data tertentu, misalnya, ke database tertentu, karena di masa depan Anda mungkin perlu mengubah metode penyimpanan. Saya melukai kumis saya dan melakukan seperti yang diperintahkan. Namun, sejak itu, alasan mengapa saya berbagi logika domain dan metode penyimpanan telah berubah, dan sebaliknya, saya mulai skeptis tentang kemungkinan mengubah database dalam produk komersial.

Dan saat menyiapkan materi ini, saya belajar tentang orang-orang yang meyakinkanbahwa banyak perusahaan berlatih mengubah basis data dalam produk yang dioperasikan secara industri. Selain itu, mengubah basis data seharusnya tidak menimbulkan rasa sakit jika Anda menggunakan sakelar fungsi. Jelas bahwa artikel tersebut ditulis oleh orang-orang yang tertarik (situs ini didukung oleh pabrikan alat komersial untuk mengelola switch), tetapi tidak ada salahnya untuk mempertimbangkan strategi beralih ke database lain yang mereka usulkan.

Jelaskan secara singkat strategi sebagai berikut. Proses dimulai dari saat ketika aplikasi kita bekerja dengan satu (lama) database. Menggunakan sakelar fungsionalitas, kami secara berurutan memaksa aplikasi kami untuk terlebih dahulu menulis data ke database baru, dan kemudian membaca data dari database baru. Pada saat yang sama, interaksi dengan database lama dipertahankan: kami berdua menulis dan membaca dari kedua database!

Jika catatan kurang lebih jelas, maka membaca harus diklarifikasi. Ketika suatu aplikasi membutuhkan data, itu membacanya dari kedua database. Kedua titik bacaan ini selalu bersebelahan sehingga setelah membaca Anda dapat membandingkan data yang diterima dan memeriksa konsistensinya. Setelah stabilisasi aplikasi (ketika kedua database mulai secara stabil mengembalikan data yang sama), aplikasi terputus dari database lama, dan sakelar dihapus.


Dimasukkannya fungsionalitas secara simultan pada platform yang berbeda

Laporan yang telah disebutkan "Fitur Toggles, atau Cara meluncurkan fitur tanpa rilis" berbicara tentang persyaratan untuk mengaktifkan fungsionalitas baru pada waktu yang sama (menit per menit!) Baik di situs maupun di aplikasi seluler. Dan kemudian Anda mungkin juga perlu mematikannya dengan cara yang sama.

Memenuhi persyaratan seperti itu tidak mudah, karena memberikan versi baru untuk platform yang berbeda sangat sulit untuk disinkronkan. Jika server dengan situs berada di bawah kendali Anda, maka Anda masih dapat menebak sesuatu (dan berharap bahwa pengiriman kali ini akan berfungsi seperti jam), maka toko aplikasi seluler dapat mengubah kebijakan untuk memperbarui pembaruan sesuai keinginan. Bagaimanapun, memperbarui aplikasi adalah proses yang panjang, yang meliputi memeriksa aplikasi yang diterbitkan oleh toko itu sendiri. Selain itu, Anda tidak boleh berharap bahwa aplikasi seluler itu sendiri akan secara teratur meminta pembaruan dari API-nya dan menginstalnya “di dalam” itu sendiri. Toko ini, seperti yang saya mengerti, juga berada di bawah pengawasan cermat pemilik platform - pasti akan ada masalah dengan pelaksanaan kode arbitrer.

Tetapi sakelar membantu memenuhi persyaratan penyertaan fungsi secara simultan dalam lingkungan di mana Anda tidak dapat sepenuhnya mengontrol pengiriman aplikasi. Jelas, pengiriman harus tetap dijamin akan terjadi sampai inklusi yang diharapkan. Metode ini mungkin akan berguna selama periode promosi sementara, seperti Black Friday.

Situasi serupa terjadi dengan beberapa modul dari satu sistem. Jika mereka diterbitkan secara terpisah dan pada saat yang sama berpartisipasi dalam mendukung satu proses dari area subjek, maka sakelar memungkinkan Anda untuk membuat perubahan terkoordinasi untuk proses ini di sisi berbagai modul.

Beralih Alat di .NET

Alat untuk bekerja dengan sakelar dapat dibagi menjadi tiga kelompok. Pertama, ini adalah produk berat universal (gabungan), yang biasanya mencakup layanan jaringan yang bekerja dengan penyedia, dan satu set perpustakaan yang memungkinkan Anda berkomunikasi dengan layanan ini untuk berbagai bahasa pemrograman. Hampir selalu, Anda harus membayar (dan banyak) untuk menggunakan produk tersebut. Kedua, ini adalah proyek yang merupakan layanan jaringan yang harus dijalankan di komputer mereka dan yang dapat diakses oleh klien melalui REST API. Dari proyek-proyek dalam grup ini (untuk singkatnya kami akan menyebutnya server), hanya mereka yang memiliki API yang terdokumentasi dengan baik atau klien resmi untuk .NET masuk ke ikhtisar. Ketiga, ini adalah pustaka sederhana (relatif terhadap dua grup sebelumnya) untuk .NET.Mereka menyarankan untuk menyimpan registri fungsionalitas dalam file konfigurasi atau mengakses registri jauh yang bukan bagian dari proyek-proyek ini melalui jaringan.

Pembaca yang penuh perhatian akan melihat bahwa ada kelompok alat perangkat lunak lain yang tidak termasuk dalam ulasan. Ini adalah produk yang dapat digunakan sebagai repositori konfigurasi untuk sistem terdistribusi. Perwakilan terkenal dari produk-produk tersebut termasuk Apache ZooKeeper , Consul dan lain- lain , dan dalam komentar di artikel ini mereka juga menyebutkan Spring Cloud Config Server, yang dapat dengan mudah berteman dengan .NET. Memang, dalam kemampuan dasarnya, switch sangat mirip dengan repositori konfigurasi, sehingga alat ini dapat digunakan sebagai titik awal untuk membuat infrastruktur switch Anda sendiri. Namun demikian, karena fakta bahwa tujuan dari sakelar fungsionalitas memiliki spesifikasi tertentu, dengan pengembangan kultur sakelar dalam proyek, kerugian dari repositori konfigurasi universal akan mulai dirasakan. Karena alasan ini, produk serupa tidak dibahas lebih lanjut.

Pemanen

LaunchDarkly

Tampaknya ini adalah produk yang paling hyped dan "geram" di bidang peralihan fungsionalitas. Orang mendapat perasaan bahwa dalam produk ini cocok dengan hampir semua yang hanya dapat terlintas dalam pikiran ketika berbicara tentang sakelar. Ini berlaku untuk kemampuan platform itu sendiri, dan berbagai klien yang tersedia, dan jenis integrasi dengan berbagai alat seperti Jira dan Visual Studio Code. Semuanya didokumentasikan dengan sangat rinci dan dengan contoh-contoh. Alat ini, tentu saja, dibayar, tetapi selama periode uji coba 30 hari dapat digunakan secara gratis.

Catamorphic Co., produsen produk ini, juga mensponsori situs referensi sakelar fitur khusus.

Microsoft.Manajemen Fitur

Pengembangan Microsoft untuk .NET Core, yang dapat digunakan dalam dua cara utama: pertama, sebagai pustaka klien, yang memungkinkan bekerja dengan sakelar dan menyimpan statusnya dalam file konfigurasi, dan kedua, sebagai gabungan, termasuk di samping pustaka ini lokasi yang terpusat untuk mengelola sakelar di Azure. Alat ini tampaknya didasarkan pada infrastruktur Konfigurasi Aplikasi Azure yang lebih umum, yang untuknya terdapat API yang terdokumentasi .

Pustaka klien menawarkan kemungkinan yang menarik untuk diintegrasikan dengan ASP.NET Core, misalnya, filter tambahan pada tindakan pengontrol dan visualisasi bersyarat tampilan, tergantung pada keadaan sakelar.

Dalam komentar untuk artikel ini, mereka menyarankan agar Anda membiasakan diri dengan seri catatan yang bergunaMicrosoft.Manajemen Fitur

Peluncuran

Situs ini terlihat bagus, tetapi ketika Anda mencoba untuk mendapatkan informasi spesifik, masalah mulai. Misalnya, diindikasikan bahwa produk memiliki banyak fitur menarik untuk mengaudit sakelar, memantau penggunaan fungsi, dan melakukan eksperimen. Tetapi pada saat yang sama, pabrikan tidak mengungkapkan kebijakan penetapan harga (hanya jelas bahwa ada uji coba gratis selama 14 hari) dan menyimpan dokumentasi REST API mereka yang cukup mentah. Dokumentasi untuk perpustakaan klien, bagaimanapun, adalah dalam urutan. Sistem mendukung penyimpanan sakelar dalam file konfigurasi.

Optimizely

Secara umum, Optimizely adalah semacam platform keren untuk mengumpulkan analitik dan melakukan eksperimen. Sistem ini memiliki bagian Peluncuran gratis .menyediakan kemampuan saklar dasar. Ada tertulis bahwa, selain mendukung penargetan ("meluncurkan" fungsi untuk kelompok pengguna tertentu), bagian bebas ini mendukung jumlah sakelar dan proyek yang tak terbatas. Selain itu, sebanyak mungkin karyawan yang Anda inginkan dapat menggunakan sistem ini. Perlu dicatat bahwa biaya banyak produk lain ditentukan dengan tepat oleh karakteristik kuantitatif ini. Berapa biaya untuk beralih ke platform yang berfungsi penuh adalah rahasia.

Bullet train

Platform ini terlihat cukup sederhana. Ia tidak memiliki fitur khusus seperti kumpulan analisis - hanya fitur utama sakelar. Saat Anda meletakkan platform di server Anda sendiri, Anda dapat menggunakannya secara gratis.

Berpisah

Platform lain yang malu harganya. Dari "chip" tambahan menawarkan integrasi dengan beberapa alat pengembangan lainnya dan dukungan untuk melakukan percobaan (pengujian A / B). Dan

ConfigCat di

sini adalah produk dengan situs yang menyenangkan di mana ada kucing. Itu terlihat provokatif. Namun, mencurigakan bahwa dokumentasi untuk REST API tidak diposting di atasnya. Dengan klien di bawah. NET semuanya baik-baik saja. Omong-omong, ada rencana gratis.

Moggles

Proyek sumber terbuka yang menyertakan server dengan situs untuk mengelola sakelar dan klien. Untuk memulai server, SQL Server diperlukan. Terlihat cukup dewasa.

Server

Unleash

Sebuah proyek open source yang cukup matang yang melibatkan hosting sistem pada server perusahaan. Termasuk situs manajemen sakelar sederhana. Ada alat sederhana bawaan untuk menjelaskan penggunaan fungsi. Instalasi cukup sederhana; Diperlukan PostgreSQL.

Tidak ada perpustakaan klien .NET resmi, tetapi beberapa yang pihak ketiga telah dibuat. Selain itu, berkat API yang terdokumentasi, secara teori, Anda dapat membuat perpustakaan Anda sendiri.

Bendera fitur Gitlab

GitLab membangun sistem sakunya di atas Unleash, sehingga pustaka klien yang sama digunakan untuk berinteraksi dengan GitLab seperti untuk Unleash. Ini berbeda dari Unleash sendiri karena Anda perlu menggali lebih sedikit dengan instalasi (kecuali untuk instalasi GitLab itu sendiri), tetapi Anda harus membayar: sakelar fungsionalitas tersedia mulai dari paket GitLab Premium (jika GitLab berjalan di server Anda sendiri) dan GitLab Silver (jika GitLab Silver berjalan di server penyedia).

Fitur flags API in Go

Proyek open source ini adalah layanan dengan API (sedikit didokumentasikan) di mana Anda dapat mengelola sakelar. Ternyata, tidak ada antarmuka grafis. Ditulis dalam Go; menggunakan basis data bawaan dan server jaringan, sehingga pengaturan, dilihat dari instruksi, sepele. Memberikan kemampuan penargetan yang belum sempurna. Terakhir diedit di repositori: 20 Februari 2019.

Bandiera

Juga merupakan proyek terbuka. Layanan dengan API dan GUI. Ditulis dalam Ruby; membutuhkan MySQL atau PostgreSQL untuk berfungsi, atau dapat diinstal dari Docker. Ada klien untuk Ruby, Node, Scala, PHP, tetapi tidak untuk .NET. Mendukung serangkaian jenis sakelar yang cukup beraneka ragam.

Flagr

Proyek open source lain di Go. Diinstal dari Docker. Ada antarmuka grafis, serta klien untuk Ruby, Go, JavaScript, Python. Ini menawarkan alat sederhana bawaan untuk akuntansi untuk penggunaan fungsionalitas dan eksperimen. Setiap sakelar dapat dikonfigurasi secara fleksibel dan dilengkapi dengan konfigurasi sendiri.

Perpustakaan Klien

Ada sejumlah besar pustaka untuk .NET yang menyediakan fitur dasar switch. Tetapi kebanyakan dari mereka berada dalam kondisi terbengkalai. Tinjauan singkat menunjukkan bahwa pada tahun 2019, hanya dua proyek yang telah diedit di repositori. Saya menemukan dua proyek lebih menarik melalui tautan di komentar ke artikel ini. Semuanya disajikan di bawah ini.

Esquio

Proyek yang paling menarik, terdokumentasi dengan baik, dan fungsional dari kelompoknya. Mesin penyimpanan internal adalah file konfigurasi atau EF Core. Ini terintegrasi sedikit dengan ASP.NET Core (seperti Microsoft.FeatureManagement); dokumentasi mengatakan bahwa menggunakan Azure dapat menyederhanakan konfigurasi sakelar.

Fitur penyihir

Itu dapat meminta status saklar baik dari file konfigurasi dan jarak jauh (itu dikonfigurasi menggunakan kelas ruang FeatureSwitch.Strategies). Dalam kit ada kerangka kerja situs web sederhana yang memungkinkan Anda mengelola sakelar. Tidak jelas apakah mungkin untuk membuat saklar yang lebih kompleks daripada on / off.

Toggle.Net

Perpustakaan paling sederhana untuk bekerja dengan sakelar, yang disimpan dalam file teks. Ternyata, itu hanya mendukung sakelar on / off. Perpustakaan Klien

RimDev.FeatureFlags

untuk ASP.NET Core. Selain memungkinkan penggunaan sakelar fungsionalitas, ia memunculkan, bersama dengan situs proyek utama, laman tambahan tempat sakelar dapat dikontrol. Mesin penyimpanan konfigurasi bawaan adalah SQL Server.

Kesimpulan

Tampaknya di banyak perusahaan sudah menjadi praktik umum untuk menggunakan sakelar untuk menjangkau saat-saat rilis versi dan dimasukkannya fungsionalitas baru. Selain itu, sakelar membantu mengurangi tingkat kegilaan saat menggabungkan cabang dalam sistem kontrol versi. Selain itu, mereka membuka jalan ke teknik populer seperti masalah kenari dan pengujian A / B.

Untuk bekerja dengan sakelar, begitu banyak perangkat lunak telah dibuat, baik yang berbayar maupun gratis, sehingga perusahaan mana pun dapat memilih alat sesuai keinginannya.

Sebagai hasilnya, saya akan mencantumkan fitur sakelar fungsi dan secara sukarela (seperti biasa) akan membaginya menjadi kelebihan dan kekurangan.

Manfaatnya

1. , — , , .
2. , . , .
3. , . , , , , .
4. , . . , «» .
5. , . , . , .

1. . , . : , . , , .
2. . , , . : , , , , . : ( ), .
3. . ? , ? . , , . ? ? : , .
4. — , . , . : (); ( ); .
5. — , . : (); «/».
6. , . : ; (, ).
7. . , ? : , , , ( ).