Re:mercurialでチケット駆動開発

元記事

default・confirm・topic*いっぱいというbranchの使い方の懸念点

リリース順≠開発完了順（チケットAは開発完了しているが優先してチケットBだけを今すぐリリースしなければいけない　という状況がありえる

ということで気になったのは、あるtopic branchでの変更について、
confirm branchにmergeして動作を確認しても、
そのtopic branchをdefault branchにmergeして正しく動作する事を保証しない、
ということ。

例えば開発完了したtopic branchがb1〜b5の5個あったとして、
b2,b4のみリリース予定は他より後になっているとする。
この時、confirm branchにb1,b2…という順番でmergeされているとして、
b5の正常動作がb2やb4での変更に依存しているとすると、
default branchにb1,b3,b5とmergeしたときに正常に動作しない。

このやり方が有効な状況

Python忘年会の時にid:feizにこの点について聞いてみたところ、
有効に機能している理由が何となく分かった。
話によるとリリースが非常に頻繁なプロジェクトなのだそうだ。
リリースが頻繁という事はつまり、
default・confirm間の差異はあまり広がらないのだろう。
後は完全な想像だが、各topic branchでの作業の独立性が高いのだと思う。

まとめるとこんな感じだろうか

default・confirm間の差異が開きすぎないように運用出来る
- 頻繁にリリースしている
各topic branchでの作業の独立性が高い
- 共通的なところは固まっていて、アプリケーションコードの新規実装や改修をモリモリやる場合とか?

懸念点の解消法法

defaultの前にRCブランチが必要かも

多分これで解消すると思う。

defaultからtopic branchを切る
以下のサイクルを繰り返す
- topic branchで開発
- 確認用捨てbranchであるconfirmにmergeして動作確認
- defaultからtopic branchにmerge(rebase)
次のリリース対象topic branch群をRC branchにmerge
RC branchで動作確認
↑で出てきたバグはRC branch上で潰す
- 場合によってはRC branchからバグ対応topic branchを切ってもいいかも?
RC branchがきれいになったら、RC branchからdefaultにmerge

3から先をやるのと同時に別ticketの1,2をやるのも問題ない。

まあ、どっちにしてもrebaseで取り込む共有成果が
リリース済み成果のみである以上、
リリースが高頻度のときに有効という点は変わらないと思うが、
topic branch間の依存によって困る事は減るのではないかと。