Re:Re:mercurialでチケット駆動開発
元記事 mercurialでチケット駆動開発 - logiqboard
id:monjudoh から懸念点を指摘されたのでもーちょっと考えてみる。
Re:mercurialでチケット駆動開発 - monjudoh’s diary
confirmで動作してもdefaultでの動作が保障されない
例えばデカい機能の新規リリースが控えている場合、「チケットxxxが、confirmにマージされたその変更に依存して正常動作している」という状況が起こりえる。
ただ元記事でも言われているように、この運用はサービスリリース後のバグフィックス・機能修正フェーズに入った後に固めた方法なので、
問題がおこらなかったという感じでしょうか。
認識を改める
confirmブランチは、実情として
"修正、機能追加の確認をする場所"
ではなく
"リリース済み成果に対する修正内容を確認する場所"
という運用がされていたというわけです。
なので機能追加に関してはこの運用だけでは対応し切れない。
じゃあどうする
"リリース前の機能Xに対する修正、機能実装の確認をする場所"
というのがあればいいんじゃなかろうか。
リポジトリ状態（想像
- 中央（hg push releaseでpushできるようにしておく）
- default ... どんなときでもリリース可能状態に保つ
- 開発環境（push先のdefaultに設定
- default
- confirm ... リリース済み成果に対する修正を集める（確認中成果も混ざる
- dev_xxx ... 機能xxxの開発ブランチ。機能xxxの開発成果を集める*1
- dev_yyy
- 中央@個人(＝個人ローカル）(hg push myでry
- default
- confirm
- dev_xxx ... 機能開発を担当している開発ブランチ
- ticketnnn ... 担当チケットのトピックブランチ*2
開発の進め方（想像
1. 大型機能xxxの開発に着手
2. dev_xxxブランチを切り、開発環境にpush
hg pull -r default release hg up default hg branch dev_xxx hg ci -m "start dev_xxx" hg push -r dev_xxx
3. 以下の手順をループ
- 機能xxxに対するチケットaaaのトピックブランチを作成
hg pull -r dev_xxx hg up dev_xxx hg branch ticketaaa hg ci -m "start tikcetaaa"
- チケット処理が完了したらdev_xxxにマージし、開発環境にpush
hg up dev_xxx hg merge ticketaaa hg ci -m "merge ticketaaa->dev_xxx" hg push -r dev_xxx
- defaultに変更があった場合はdev_xxxをrebase
hg pull -r default release hg up dev_xxx hg merge default hg ci -m "rebase"
4. 機能xxxの動作確認は、開発環境のブランチをdev_xxxに切り替えて行う
hg up -C dev_xxx
5. 確認が取れたらdefaultにmerge
hg pull -r default release hg up default hg merge dev_xxx hg ci -m "release dev_xxx" hg push -r default release
前回との違い
チケットを直接defaultにmergeしてリリース状態にする代わりに、機能ブランチにチケットを集約するというワンクッションを置くようにした。
実際のところ、1チケットを処理する為の作業量もリリース状態にする際の作業量も前回とほとんど変わりないはず。
confirmブランチを使った確認と組み合わせて使えば、大体の状況には対応できそう。
どこからが「機能」か
- チケット間に依存がある
- 1チケット処理しただけではリリース出来ない＝confirmブランチにマージしても確認できない。
- 担当者が複数居る
- チケットの変更分を機能ブランチで共有しないといけない。
上記を満たすなら機能ブランチを切る必要がある。
依存するチケットが数枚程度＋担当者が自分一人の場合は機能ブランチを切らなくてもなんとかなる。
ただしdefaultへマージするときは、どのチケットをマージしなくてはいけないかよくよく確認しないといけない。
