GitHub FlowとTrunk-based開発、どっちがボトルネックになる？インタラクティブなシミュレーターで可視化しよう

はは、その可能性もあるね！ただ個人的には、Thoughtworksで実際にやっていた頃（CDが発明された場所でもあるし）に、15年間現場でチームがこれらを実践するのを見てきた経験に基づいているよ。

いい仕事だね。ちなみにThoughtworksには何年いたの？

確か2013年〜2019年と、2022年〜2024年だったと思う

自分は短命ブランチとPRを使った「GitHub flow」が経験上しっくりくるかな。Trunk-based developmentもかなり良いんだけど、なぜか使わなくなったんだよね…理由はよく分からないけど。フィーチャーフラグは素晴らしいけど、リファクタリング全体をフラグ化するのは難しいし、複数のAPIバージョンを管理するのは大変だしね。

GitFlowは…個人的にはやりすぎだと思う。誰が何のためにあんな複雑なことをしたがるのか分からない。カーネル開発みたいに、世界中の何千人もの人から大量のパッチを受け取って、いくつものバージョンを並行管理するなら必要かもしれないけど、自分たちのような一般的な開発には当てはまらない気がするな。

リファクタリング全体をフィーチャーフラグにするのは無理

データベースが絡んでくると特に複雑になるよね。でも、ブランチを使うよりはマシだと思うな。あと、リファクタリングの影響範囲が広いなら「Branch by abstraction」や「Dark launching」の方が安全かもしれない。最近フィーチャーフラグ周辺のビジネスが流行ってるけど、何でもフラグを使えばいいってわけじゃないしね。

機能フラグは素晴らしいけど、リファクタリング全体を機能フラグで制御するのは無理だし、複数のAPIバージョンを維持するのは面倒だよね。

実はそのケースで機能フラグに助けられた経験があるんだ。重要なワークフローソリューションを新システムへ移行する際に約3000行のコード変更が必要だったんだけど、結局それを機能フラグで隠したんだ。良かった点は、エンドツーエンドの整合性テストを組み込んで、新旧両方のロジックが同じ挙動をするか確認したことだね。おかげで設計中にレガシー側に何か変更が入っても、テストで検知して適切に更新できたんだ。

1. いい指摘だね。シミュレーションには20個くらいのコンフィグ用ノブがあるんだけど、今はユーザーからは見えないようになってるんだ。
2. 適当なLGTMですでに本番バグは発生するようにしてるけど、ログだと少しわかりにくいよね。
3. それも同意。Git flowには「Build」があるけど、GitHub flowはたまに試してくれるから少し甘く見てたかも。

V2で改善しておくよ…あ、MVP v2ね。

長期間ブランチを残す手法には向いているね。でも、そもそも「なんでそんなにブランチが長期間生きているの？」という疑問が当然湧いてくる。それは大抵、組織の機能不全やアジリティの欠如を反映しているものだから、それが存在すること自体を否定はしないけど、それを「推奨」する奴がいたら正気を疑うね。

サンクス。フィードバックを元に透明性を上げたから、バグが発生した時に何が原因でそうなったのかログに表示されるようになったよ。

バグ発生の計算式は全モード共通だけど、TBDは構造的にバッチサイズが1になるからバグ率が低くなるんだ。シミュレーション自体は、なぜ数値が乖離するのかを説明するものではないからね。

確かにTBDに対しては非常に偏っているよ。実プロジェクトでTBDと他のモードの両方を経験して、良さを知っているからね。これはあくまで裏紙に書いたようなお遊びのシミュレーションであって、学術論文じゃないんだ。DORAの連中がすでにそういうのはやってるしね。

要するにモデルが間違っているから、そこから結論を導き出すことはできないってことだよ。

まず、これはお遊びレベルのシミュレーションであって研究論文じゃないってことを理解してくれ。各ドットは作業項目で、青はストーリー、オレンジはレビューや手戻りだ。GitHub Flowの「待機中」カラムが埋まっていくのを見てほしい。それが作業の停滞だ。TBDタブに切り替えると、パイプラインは空のままだろう。何も待機していないからね。一番下の数値は、完了、WIP、キュー、リードタイムを表しているよ。