Tim kami mempraktikkan pendekatan Pengembangan Berbasis Batang - kode baru segera ditambahkan ke cabang master, cabang pihak ketiga aktif selama maksimal beberapa hari. Dan agar komit tidak mengganggu satu sama lain, pengembang menggunakan Tanda Fitur - sakelar dalam kode yang memulai dan menghentikan pekerjaan komponennya.
Pertimbangkan iterasi pengembangan yang khas: perencanaan, menentukan persyaratan, membuat tugas di pelacak, pengembangan. Saat tugas siap, tugas tersebut disebarkan di lingkungan pengujian untuk pengujian, cabang rilis menjadi stabil. Kemudian rilis akhirnya datang dan tim akhirnya bisa mendapatkan umpan balik yang nyata dari pengguna.
Jika Anda ingin mengurangi Time-to-Market, itu terlalu lama. Semakin cepat Anda mendapatkan umpan balik dari pengguna, semakin cepat Anda memperbaiki kesalahan, semakin sedikit waktu yang Anda habiskan untuk ide buruk, semakin banyak sumber daya yang dapat Anda curahkan untuk ide-ide sukses.
Agar pembaruan mencapai penjualan lebih cepat, satu iterasi harus menyertakan satu fitur. Itulah mengapa perlu memperpendek umur cabang.
Masalah cabang berumur panjang
Konflik antar commit (Gabungkan neraka). Menunda rilis, integrasi dengan sistem eksternal, dan faktor eksternal lainnya dapat membuat penghitungan tidak berfungsi.
Kesulitan dengan berbagi kode. Anggota tim lain mungkin memerlukan kode dari cabang baru jika fiturnya saling bergantung. Kami harus memulai cabang lain hanya untuk mengakses kode ini.
Menguji masalah lingkungan. Jika hanya ada satu server uji, dan ada banyak cabang fitur, itu tidak akan berfungsi untuk menguji tugas secara paralel.
Sulit untuk mengembalikan perubahan. Masalah setelah rilis sering terjadi, dan jika cabang fitur baru mulai gagal, pengembang harus memilih antara perbaikan terbaru dan sebaliknya, masuk ke kode sumber, dan mengunggah ulang solusi.
Bagaimana Pengembangan Berbasis Batang Memecahkan Masalah Ini
Trunk Based Development ( . trunk – « ») – . Gitflow, TBD master. feature- , .
Trunk Based Development , trunk. , , , -. .
trunk -. , . trunk , .
, - , ? Feature Flags.
Feature Flags
, IF-, . – , . : , - . – , .
(toggle router), . , , . ( ), (, , , ..).
Feature Flags
- , :
(release toggles): , , . .
(experiment toggles): A/B , . % , .
(permission toggles): . , .
(ops toggles): . , – , .
### Feature Flags
– .
– - , .
– TBD , .
: LaunchDarkly, Bullet-Train, Unleash. - , - . , .
Open source : Moggles, Esquilo. , , . , , .
: , . , . .
Feature Flags Portal (FF-Portal): Web + REST API . .
Feature Flags Storage (FF-Storage): .
Kubernetes ConfigMap (FF-configmap): k8s ConfigMap , , FF-Storage . FF-Portal FF-configmap.
Microservice (MS): , FF-configmap . FF-configmap, .
FF-ConfigMap, Pod- . ConfigMap, k8s , .
Bendera diubah melalui portal, yang mengirimkan pesan integrasi ke bus saat status diperbarui. Komponen Config Updater memperbarui nilai bendera di FF-ConfigMap melalui K8S API.
Terakhir tentang pengujian
Muncul pertanyaan, bagaimana cara menguji produk dengan fitur flags? Sekilas, flag memperumit proses ini - jika ada banyak sakelar, maka jumlah semua kemungkinan status meningkat secara dramatis.
Tetapi bendera tidak selalu bergantung satu sama lain. Oleh karena itu, kami menguji dua kasus pembatasan untuk rilis: 1) semua flag baru nonaktif dan 2) semua flag aktif.
Latihan menunjukkan bahwa ini biasanya sudah cukup.