Trunk-based developmentという開発手法があります。 State of DevOps 2019では、ソフトウェアのデリバリ能力、ひいては組織パフォーマンスをドライブする要素の1つであるとされています。
(図もState of DevOps 2019から引用)
Trunk-based Developmentとは
Trunk-based Developmentは、各コミッタが直接trunkにコードをプッシュするか、あるいは短命なbranchを作ってガンガンtrunkにマージ1するという戦略です。
(図はIntroductionより引用)
その狙いは以下の2点で、その効果はDORAのレポートで立証されています。
- マージするコード量が少ないため、マージに伴うリスクが小さい
- 開発タスクのサイズが大きくても数日サイズとなり、バッチサイズが小さくなる
2016 年（PDF）と 2017 年（PDF）の DevOps Research and Assessment（DORA）の分析結果は、チームが次のプラクティスに従うことで、より高いレベルのソフトウェアを配信し、運用パフォーマンス（配信速度、安定性、可用性）を改善できることを示しています。
- アプリケーションのコード リポジトリに 3 つ以下のアクティブなブランチを用意する
- 少なくとも 1 日に 1 回、ブランチにトランクをマージする
- コードフリーズや統合フェーズをなくす
果たして現場で
現場適用したいなぁと思っているのですが、思考実験をしているとなかなか厄介でして。
trunkはRelease Readyであることが前提です。 つまり、trunkにmergeされたコードは、本番リリースの品質が担保されている必要があります。 これは結局、デプロイメントパイプラインの頑健さ、テストの高い信頼性と自動化が求められます。
また、本番環境デプロイまでにステージング環境でのテスト等が求められる場合は、それもデプロイメントパイプラインに統合することが求められます。 複数環境にまたがったデプロイメントパイプラインをmergeの都度、高速に実行していく仕掛け作りは結構ハードルが高そうです。
参考文献
-
少なくともfeature branchの寿命は数日。↩
