Jawaban:
Bendera fitur adalah perangkat rekayasa yang dapat digunakan untuk menghindari cabang yang berumur panjang dan konflik dalam pengembangan produk. Berikut ini adalah bagaimana ia dapat digunakan konteks bahasa berorientasi objek untuk membantu pengembang berkolaborasi pada fitur produk tertentu sementara satu menangani versi baru. Solusi ini juga dapat digunakan dalam konteks yang tidak berorientasi objek, asalkan ada “antarmuka”. ( lih . sistem modul OCaml.)
Untuk tujuan ilustrasi, kami mengasumsikan alat menyajikan laporan tentang data yang disimpan dalam database. Kode mengimplementasikan kelas DatabaseClient yang digunakan untuk melakukan permintaan. Ketika dataset bertambah, menjadi jelas bahwa beberapa tata letak data alternatif akan meningkatkan kinerja aplikasi. Oleh karena itu Alice akan mengembangkan versi baru dari DatabaseClient yang dapat mengambil data dari struktur dengan tata letak yang ditingkatkan, sementara Bob akan mempertahankan DatabaseClient historis .
Dengan langkah-langkah berikut, Alice dan Bob dapat berkolaborasi di cabang yang berumur pendek sambil meminimalkan konflik mereka.
Alice mengganti nama DatabaseClient ke DatabaseClient_v1 dan membuat kelas delegasi bernama DatabaseClient yang menggunakan objek DatabaseClient_v1 dan mengimplementasikan antarmuka yang disebut DatabaseClientInterface. (Jika mungkin, DatabaseClientInterface ini harus berupa artefak kode tetapi bahasa yang diketik bebek tidak selalu mendukung hal ini.)
Bob meninjau perubahan yang dilakukan oleh Alice in 1 dan menyadari bahwa pekerjaan pemeliharaannya harus terjadi pada DatabaseClient_v1 .
Alice memperkenalkan flag konfigurasi baru dalam aplikasi yang mengatur perilaku delegasi DatabaseClient dan mengimplementasikan placeholder DatabaseClient_v2 , kelas yang mengimplementasikan DatabaseClientInterface yang metodenya melempar pengecualian “Tidak diimplementasikan”.
Setelah ini, Alice dan Bob dapat berkolaborasi tanpa sinkronisasi eksplisit, karena kode yang ditulis dalam iterasi masing-masing tunduk pada DatabaseClientInterface . Ini meminimalkan risiko konflik yang dihasilkan dari pekerjaan bersamaan mereka.
Iterasi dari Alice bisa sangat singkat, seperti melaksanakan tes, menerapkan metode, atau bahkan melakukan sebagian, karena dalam produksi, kode tidak dipilih untuk digunakan dan tidak perlu berfungsi penuh. Testuite otomatis harus dikonfigurasikan agar DatabaseClientInterface selalu menggunakan DatabaseClient_v1 sementara Alice dapat dengan mudah beralih ke DatabaseClient_v2 saat menjalankan testuite secara lokal - atau dalam pengaturan CI kustom. Setelah semuanya siap, komit tunggal dapat melakukan perubahan, dengan memperbarui nilai konfigurasi yang mengatur delegasi DatabaseClient .
Langkah-langkahnya cukup "mudah", untuk pindah ke aplikasi fitur bendera pada dasarnya Anda membutuhkan dua hal:
Dasar dari flag fitur adalah untuk menghidupkan / mematikannya, tetapi dengan cepat Anda akan ingin merilis fitur baru dengan cara ramp-up, misalnya: 1 server pada 5 hosting aplikasi memiliki fitur "on" untuk memulai, Anda kemudian menyalakan fitur di server lain, sampai semua server "aktif".
Ini berarti Anda harus berhati-hati tentang fitur yang kompatibel dengan aplikasi tanpa itu (misalnya kolom tambahan dalam DB).
Kerangka kerja ada dalam berbagai bahasa untuk menghindari reinventing the wheel, yang sekarang tidak terawat dari Etsy memiliki readme yang menarik untuk menjelaskan cara kerjanya.
Dunia perangkat lunak tertanam sering menggunakan flag build-time, dalam kode aplikasi itu sendiri ( #define/ #ifdefmisalnya, pernyataan) dan / atau dalam file konfigurasi alat bangun ( makefilemisalnya,).
Bangun bendera dapat digunakan, dengan cara yang sama, tidak hanya untuk fitur, tetapi juga untuk semua jenis refactoring kode, migrasi, dukungan debug, dll). Mereka mengizinkan melakukan di cabang integrasi perubahan sebagian atau tidak diverifikasi tanpa merusak build atau menyebabkan regresi pada fitur / proyek yang sudah bekerja di cabang. Sangat baik untuk menangani perbaikan titik di samping perubahan kemajuan besar / berisiko / lambat (yang sebaliknya membutuhkan cabang berumur panjang) dengan cara integrasi berkelanjutan.
Tetapi selain memverifikasi kode cabang yang sudah ada untuk regresi, juga dimungkinkan untuk melakukan verifikasi progres / stabilitas kode baru. Untuk ini, flag build-time perlu di-toggle.
Salah satu cara mengubah flag adalah dengan menggunakan, dalam pipa verifikasi terpisah dari sistem CI dari cabang yang sama (jika memiliki dukungan untuk fungsi tersebut), patchfile mengubah flag - untuk diterapkan ke ruang kerja terpisah sebelum membangun. Seperangkat artefak yang berbeda akan dibangun di ruang kerja ini dan kemudian diverifikasi.
Atau cabang fitur yang berumur panjang dapat ditarik dari cabang integrasi utama, tetapi satu-satunya perubahan dalam cabang fitur ini adalah flag yang di-toggle. Karena perubahan kecil ini, cabang fitur dapat secara otomatis disinkronkan dengan sangat cepat - praktis membayangi cabang integrasi utama. Eksekusi CI terpisah pada cabang ini tidak perlu patchfile awal lagi. Akan sepele untuk membawa-bawa cabang fitur seperti itu bahkan untuk jangka waktu yang lama.
Dimungkinkan juga untuk membuat, di cabang integrasi utama, artefak build baru yang benar-benar hanya klon dari artefak build yang ada tetapi dengan flag yang di-toggle. Dengan cara ini baik patchfile awal maupun cabang fitur tidak perlu untuk memverifikasi kode baru, tepat di cabang utama.