mercurialでチケット駆動開発

mercurial

本格的にmercurialを使い始めて数ヶ月、色々ノウハウがたまったのでまとめてみる。

想定する状況

  1. VCSはmercurial一本で運用
  2. IssueがなにかしらのBTSで管理されており、チケット単位でかつ並列に開発を進めたい
  3. リリース順≠開発完了順（チケットAは開発完了しているが優先してチケットBだけを今すぐリリースしなければいけない　という状況がありえる

リポジトリ配置

中央(central)
どこかの共有サーバー上にあり、全ての開発成果が集まる場所。
中央@個人用(default)
↑と同じ場所にある個人の開発用の中央リポジトリ。個人ローカルと完全に同期する。
確認環境(test)
中央からclone, pullされる。リリースチェック、各チケットの動作確認を行う。
個人ローカル
個人の開発環境上に置かれるリポジトリ。やりたい放題する。

ブランチ運用

default
リリースブランチ。常にリリース可能な状態である必要がある。
confirm
確認ブランチ。確認環境は常にこのブランチで稼動している。
ticketXXX
各チケットごとのブランチ。defaultブランチをベースとする

開発の進め方

1. 自分担当のチケットで、着手するものに関してticketXXXでブランチを切り、チケットのステータスをassignedとする

hg up default
hg branch ticketXXX
hg ci -m "start"

2. ticketXXXブランチ上で開発する。

    • 既に着手されたチケットの担当者変更の場合は、元担当者の中央個人用リポジトリからチケットのブランチをpullしてくる。
hg pull -r ticketYYY daresore
    • チケット開発中にリリースブランチの更新があった場合はすぐにrebase作業を行う。
hg up ticketXXX
hg merge default
hg ci -m "rebased"

#hg rebaseなどという機能もあるらしいが微妙とのことなのでmergeする。→http://d.hatena.ne.jp/monjudoh/20090907/1252347458


3. 開発が完了したらconfirmにmergeして中央にpushし、チケットのステータスをresolvedにする。

hg up confirm
hg pull central
hg merge ticketXXX
hg ci
hg push -r confirm central

#-r confirmは忘れずに。チケットごとのブランチを中央に上げるとカオスになって、そこからcloneした人の頭がおかしくなって死ぬ


4. 確認が通ったらチケットをverifiedにして各チケットブランチ->リリースブランチにマージする

hg up default
hg pull central
hg merge ticketXXX
hg ci 
hg push -r default

#間違ってもconfirm->defaultというマージをしてはいけない。confirmには未確認の修正も混ざり得るので。


5. リリース可能状態。

やってみての感想

わりとイケテル

  • 開発順≠確認順≠リリース順という嫌な状況にも苦もなく対応できるというのがかなり助かる。
  • BTS上のチケット状態とリビジョングラフの状態の対応が取れる*1ので進捗管理しやすい
  • すっごいmercurialしてる気になれてたのしい。

TODO

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

*1:なくもない