Mercurialによるチケット駆動開発は強力だ！

Mercurialを使ったチケット駆動開発の記事が非常に素晴らしいのでメモ。
このやり方を使いこなせれば、ソフトウェア開発の生産性は劇的に上がると思う。

【元ネタ】
mercurialでチケット駆動開発 - ろじぼ

上記の記事を理解できた範囲でまとめてみた。

Mercurial＋TiDD from akipii Oga

【仮定】
・SCMはMercurial。(Gitでも良い)
・BTSチケットでSW開発のタスクを管理する。

・trunk、confirmブランチは中央リポジトリ(サーバー)にある。
・チケットブランチ(トピックブランチ)は、ローカルとサーバーの2箇所にある。
　常時同期されている。
・作業の優先順位によって、チケットがリリース順≠開発順の状況はある。

【チケットAブランチ上の作業手順】
1・チケット担当時に、ブランチ作成。【チケットのステータス＝担当】
↓
2・チケットAブランチ上でガンガン開発する。【チケットのステータス＝担当】
　→trunkの更新は随時マージ(pull)して、最新機能を取り入れる。
↓
3・チケットA解決時、confirmブランチへpush。【チケットのステータス＝解決】
↓
4・チケットA検証はconfirmブランチで行う。【チケットのステータス＝検証中】
　テスターはconfirmブランチで検証する。
　confirmブランチはたくさんのチケットを検証するコードラインなので、trunkよりも品質は劣る。
　confirmブランチはtrunkからpullされるが、pushはしない。
↓
5・バグを検知したら、チケットAブランチで修正して、confirmブランチへpushする。【チケットのステータス＝フィードバック】
↓
6・confirmブランチでチケットA検証完了後、チケットAブランチからtrunkへpushする。【チケットのステータス＝検証完了】
　→confirmブランチからtrunkへpushしない。
　　confirmブランチには他チケット検証も混じっているから、trunkへマージすると中途半端な機能も取り込まれてしまうから。

上記のやり方が優れているのは、チケットブランチ(トピックブランチ)だけでなく、チケットの修正パッチをconfirmブランチで検証している点だ。

チケットをトピックブランチにして開発し、チケットの修正パッチをtrunkへマージする場合、チケットの修正パッチにバグがあれば、trunkの品質は落ちてしまい、リリースできなくなる。
だから、confirmブランチでテスターが別途検証できるコードラインを作っておく。
当然バグがあれば、テスターは担当者に差し戻し、バグ修正したソースをpushしてもらって更に検証する。

この時、confirmブランチでは、担当チケットの検証以外にも、複数の担当者、複数のチームが開発したソースを並行して検証中している状況は多い。
これが「リリース順≠開発順の状況」の意味。
つまり、confirmブランチはtrunkよりも更に最新の機能が実現されているが、品質はtrunkよりも劣る。
だから、trunkへマージするタイミングが非常に重要。
マージするソースの品質が安全でないのにtrunkへマージしてしまうと、デグレが起きてしまうから。

そして、チケットの修正が終わったら、チケットブランチからtrunkへpushする。
以前は、このconfirmブランチ上でチケットの作業を実施し、CVSやSVNのタグを付けて、チケット(バグ報告票)の番号と関連付けたExcelのリリース一覧で管理していた。
このExcelのリリース一覧を見て、ライブラリアンは、リリース順(≠開発順)にタグをtrunkへ手作業でマージしていた。
だから、この作業はとても煩雑で慎重に行う必要があった。

しかし、上記のやり方ならば、チケットブランチからturnkへのマージ作業を自動化できるので、ミスしにくくなるだろう。

普通は、trunkが本番ソース、開発サーバーのソースがconfirmブランチに相当するだろう。
開発者やテスターが意識するのは、confirmブランチであり、trunkを触れる人はライブラリアンだけにすれば、より厳重な品質管理ができた運用になる。
但し、trunkからtag付けして本番リリースする場合、本番リリースブランチをtrunkとは別に作る時もあるだろう。

このやり方は特に大規模プロジェクト・組込み製品・パッケージ製品のような並行開発が行われている環境で威力を発揮すると思う。
何故なら、似たようなコードラインがたくさんある状況では、バグ修正やマージ作業のミスが致命的になりやすいから。

分散バージョン管理とチケット駆動開発は非常に相性が良いと思っている。
そして、この2つの組合せに、ビルド管理ツールHudsonやテスト管理ツールTestLinkなどを連携できると、まさにワンクリックでいつでもリリースできるようになる。

つまり、この「いつでもリリースできるようになる」技術があるからこそ、アジャイル開発の運用が可能になる。
アジャイル開発が普及しない理由は改めて、殆どの開発チームは単純に技術力が無いだけだと思う。