ReviewBoardとMercurial＋TiDDは相性が良い？

Mercurialによるチケット駆動開発の仕組みがコードレビューのプロセスに似ているアイデアをメモ。
＃ラフなメモ書き。

【元ネタ】
ReviewBoard | Documentation | General Workflow

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

コードレビューWebシステムReviewBoardには、「pre-commit review」「post-commit review」の2種類のやり方がある。
ReviewBoardは「pre-commit review」の考え方で作られている。
つまり、改変したコードをtrunkにコミットする前にレビューを受けるプロセス。
多分、オープンソースの開発ではよく使われているコードレビュー手法だと思う。

開発者は、SVNなどでdiffを作り、ReviewBoardリクエストに登録し、レビューアのレビューを受ける。
つまり、trunkにすぐにコミットせず、自分のローカルに修正パッチを保持し、レビューアの指摘を反映して、OKが出たら、trunkへ初めてコミットできる。
このやり方は、trunkに中途半端なソースをコミットしないための運用ルール。

「post-commit review」は、改変したソースをtrunkとは別ブランチに作り、レビューを受けるプロセス。
「post-commit review」のレビュー方法は、Mercurial＋TiDDでもっと簡単になるはず。
そのアイデアをまとめてみた。

ReviewBoard＋TiDD from akipii Oga

つまり、チケット単位にMercurialのトピックブランチを作り、担当者はトピックブランチでガンガン開発する。
そして、ソース修正が終われば、チケットを解決ステータスにし、ReviewBoardリクエストへ登録してレビューを依頼する。
この時、ReviewBoardリクエストとRedmineチケットを相互リンクさせておく。

そして、レビューアの指摘を受けてMercurialのトピックブランチ上で修正し、レビューOKが出たら、初めてtrunkへpushする。
MercurialやGitならば、トピックブランチの管理が簡単で、trunkから最新機能を随時pullすればいい。
当然このやり方でも、trunkに中途半端なソースはマージされないので、trunkの品質は保たれる。

ReviewBoard上のコードレビューはRedmineチケットと紐づいているため、Redmineのワークフロー管理機能を使って、レビュー用プロセスを容易に管理できる。
もちろん、進捗管理も可能だ。

おそらく、コードレビューが重要と誰もが知っているのに実プロジェクトで運用できない原因は、分散バージョン管理のようなインフラがない為にソースの品質管理が難しく、ReviewBoard＋TiDDのようなインフラがない為にコードレビューをワークフロー管理するプロセスが曖昧だからだろう。

Mercurial、TestLink、Hudsonなどのツールと連携したチケット駆動開発には色んな可能性を感じている。
ツールを駆使して、SW開発の生産性を上げてプロセス改善していくやり方は、もっと研究されていい気がする。