私たちのチームはトランクベースの開発アプローチを実践しています-新しいコードはすぐにマスターブランチに追加され、サードパーティのブランチは最大数日間存続します。また、コミットが相互に干渉しないように、開発者は機能フラグを使用します。これは、コンポーネントの作業を開始および停止するコード内のスイッチです。
典型的な開発の反復を考えてみましょう：計画、要件の指定、トラッカーでのタスクの作成、開発。タスクの準備が整うと、テスト用にテスト環境にデプロイされ、リリースブランチが安定します。その後、ついにリリースが始まり、チームはついにユーザーから実際のフィードバックを得ることができます。
市場投入までの時間を短縮したいのであれば、それは長すぎます。ユーザーからのフィードバックを早く受け取るほど、間違いを早く修正するほど、悪いアイデアに費やす時間が少なくなり、成功するアイデアに費やすことができるリソースが増えます。
アップデートをより早く販売に到達させるには、1回の反復で1つの機能を含める必要があります。そのため、枝の寿命を短くする必要があります。
長期にわたるブランチの問題
コミット間の競合（マージ地獄）。リリースの遅延、外部システムとの統合、およびその他の外部要因により、カウントが機能しなくなる可能性があります。
コード共有の難しさ。機能が相互に依存している場合、他のチームメンバーは新しいブランチからのコードを必要とする場合があります。このコードにアクセスするためだけに、別のブランチを開始する必要があります。
テスト環境の問題。テストサーバーが1つだけで、機能ブランチが多数ある場合、タスクを並行してテストすることはできません。
変更をロールバックするのは困難です。リリース後の問題は一般的であり、新しい機能ブランチが失敗し始めた場合、開発者はホットフィックスとリバースのどちらかを選択し、ソースコードに移動して、ソリューションを再アップロードする必要があります。
トランクベースの開発がこれらの問題をどのように解決するか
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 , .
フラグはポータルを介して変更されます。ポータルは、ステータスが更新されると統合メッセージをバスに送信します。Config Updaterコンポーネントは、K8SAPIを介してFF-ConfigMapのフラグ値を更新します。
最後にテストについて
機能フラグを使用して製品をテストするにはどうすればよいかという疑問が生じます。一見すると、フラグはこのプロセスを複雑にします。スイッチが多数ある場合、考えられるすべての状態の数が劇的に増加します。
ただし、フラグは常に相互に依存しているわけではありません。したがって、リリースの2つの限定的なケースをテストしています。1）すべての新しいフラグがオフで、2）すべてのフラグがオンです。
練習では、通常これで十分であることが示されています。