Mercurial以前と以後のチケット駆動開発

Mercurialのような分散バージョン管理を組み合わせたチケット駆動開発とそれ以前の開発スタイルの違いをまとめる。

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

Mercurialによるチケット駆動開発は強力だ！: プログラマの思索

ReviewBoardとMercurial＋TiDDは相性が良い？: プログラマの思索

Mercurial＋TiDD from akipii Oga

【Mercruial以前のTiDD】

「Mercurial以前のチケット駆動開発」シートにあるように、trunkと本番ブランチの2本でソース管理している。
基本は、trunkはリファクタリングや機能追加、本番ブランチは障害修正のみ行い、ソース修正の目的をコードライン単位に使い分ける。
理由は、コードラインの品質を維持したいからだ。
リファクタリングや障害修正、機能追加をtrunkの1本のみで行うと、突然の本番障害に対応できなくなるからだ。
そして、リリース予定のバージョンをtrunkからリリースするタイミングで、タグ付けして新しいバージョンの本番ブランチを作成していく。

これがメインラインモデルによる構成管理の原形。
つまり、本番ブランチはtrunkよりも品質が高く、硬いコードラインになる。
「硬い」という意味は、品質が安定しているだけでなく、ソースを触る作業も障害修正の目的以外は許されない意味も含んでいる。

すると、本番ブランチで障害修正を施した場合、trunkへマージする作業が発生する。
Subversion＋Redmineでは、「障害修正」と「マージ作業」のチケットを別々に作り、相互に関連付けていた。
そして、マージ作業のタイミングは、trunkへガンガン機能追加中のチケットの進捗と調整して、優先度を付けていた。
当然、trunkのリリース予定バージョンにマージ作業も機能追加のチケットもアサインされる。

つまり、チケットのリリース順は、ロードマップのバージョン単位に分割するため、バージョンの順番になる。
そして、チケットの開発順は、バージョンの内部でチケットの優先順位を付ければいい。

チケット駆動開発では、チケットの関連やチケットの進捗が見えやすいので、マージ作業をTODO管理のイメージで運用していた。
但し、マージ作業は手作業のままであり、タグ付られたリビジョンを参考にマージ作業を慎重に行う必要はあった。

【Mercurial以前の大規模プロジェクトの構成管理】

大規模プロジェクトでは更にこの状況が複雑になる。
本番ブランチとtrunkの扱いは基本はほぼ同じだが、テスト環境ブランチを別途作る時が多い。

テスト環境ブランチは、サブの開発チーム単位に作られ、バグ修正や機能追加などを行う。
trunkと別ブランチにする理由は、複数のサブチームのソースがtrunkに混じると混乱しやすいからだ。
つまり、trunkを常時リリース可能なラインにするために、テスト環境ブランチをタスクブランチのように扱う。

テスト環境ブランチ上で、開発者は修正し、テスターは検証する。
検証完了になったら、タグ付けし、trunkへマージしてリリースする。

このリリース作業では、普通はライブラリアンがExcelのリリース作業一覧を作っており、このExcelの一覧に従って、タグを見ながら慎重にマージしていく。
理由は、開発順とリリース順が異なる場合は多いからだ。
リリース順序は、複数のサブチームを統括するプロマネがユーザと調整して決まるが、裏では開発を先取りしている時も多い。

だから、Excelのリリース作業一覧が常に最新化されているのが重要になってくる。
結局、複数人が手作業で厳重に管理するプロセスになり、機動性は低くなる。

【Mercruial＋TiDD】

「Mercurialによるチケット駆動開発」は「Mercurial以前のチケット駆動開発や「Mercurial以前の大規模プロジェクトの構成管理」を更に洗練させた構造になる。
つまり、テスト環境ブランチをconfirmブランチとして扱い、Mercurialのpull＆pushでtrunkやconfirmブランチのマージ作業を自動化して、trunkを機能が最新かつ常時リリース可能な品質に保てる。
更にチケット単位にトピックブランチを作り、トピックブランチをタスクブランチのように扱うことで、trunkやconfirmブランチに品質が不十分なソースをコミットする危険性を防いでいる。

このようにブランチをたくさん作っても安心できるのは、分散バージョン管理の優れたマージ機能(pull＆push)があるおかげだ。

またこの開発スタイルは、オープンソースの開発プロセスに似ている。
つまり、トピックブランチがハッカーが作業するパッチ当てのコードラインに対応し、trunkへのリリースは、コミッタのレビューがOKの場合、trunkへパッチが反映される手順に相当するからだ。

分散バージョン管理のおかげで、SW構成管理の作業品質は確実に上がる。
チケット駆動開発と組み合わせれば、複雑なリリース作業を楽にしてくれるはずだ。