チケット駆動開発に分散バージョン管理を組み合わせるアイデア

チケット駆動開発に分散バージョン管理を組み合わせるアイデアについてラフなメモ書き。

【元ネタ】
TiDDとgit-flowを合わせた開発手法について | Technology-Gym

gitとRedmineと連携させるgitサブコマンド: git-ticket - みずぴー日記

Git-Redmine: GitのコミットとRedmineを連携する。チケット駆動開発にも。 (ゆめ技：ゆめみスタッフブログ)

PullRequestは分散バージョン管理の利点を生かしたパッチ取り込み: プログラマの思索

git-flow による構成管理とRedmineの関係: プログラマの思索

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

Mercurial以前と以後のチケット駆動開発: プログラマの思索

RedmineのVer1.4からマルチSCMリポジトリ機能が実装されたことによって、trunkとトピックブランチなどの派生ブランチも一つのプロジェクトに含めることができる。
すると、トピックブランチ上で修正したパッチをtrunkへマージしてもらう時に、GitHubのPull requestと同様の機能をRedmine上でも事実上実現できる。
すなわち、trunkからトピックブランチを派生する場合は、folkするチケットを作ればその作業履歴が残るし、トピックブランチをPullする場合は、どのリビジョンのソースをとり込んだのかをコミットログのチケット番号に書いておけば、チケットにコミット履歴が残る。

特に、@haru_iidaさんが作られたCodeReview Pluginには、チケットの属性にリビジョンがあるので、folkやpullする場合にCodeReviewプラグインを使ってもいいかもしれない。
そうすれば、チケットのリビジョンにコミット履歴が残るようになり、後から検索しやすくなる。

Redmineのリポジトリ参照画面では、GitやMercurialのような分散バージョン管理の場合、git log --graphやhg log --graphのような色つきブランチが表示されるので、どのようの派生してマージされたのかが分かりやすい。

以前の僕は、Redmineのバージョンが古くて機能が限られていたため、Redmineの複数プロジェクト機能を並行開発に適用して、ブランチ単位にプロジェクトを割り当てるように運用していた。
この手法は、確かに製品単位のタスク管理には有効だが、トピックブランチのようにブランチの生存期間がとても短い場合はあまり向かない。
つまり、ブランチの生存期間と製品の生存期間が対応している場合は、複数プロジェクト機能を使ってプロジェクトを分割した方がいいが、分散バージョン管理のように実験的なブランチをどんどん作る場合にはあまり向かない。

だから、一つのプロジェクトで、派生したブランチは全てまとめる方がチケット駆動開発に向いているかもしれない。
git-flowのように、各種ブランチを目的を持って作り、最後はmaster(trunk)へマージして育てていく開発スタイルには、チケット駆動開発を組み合わせればより強力になるだろうと思っている。