pre-commit-hookとpost-commit-hook #tidd

Subversionには、pre-commitとpost-commitの機能が元々付いている。
復習のためにメモ。

【元ネタ】
TortoiseSVN の設定

バグ追跡システム / 課題追跡システムとの統合

[Think IT] 第4回：チケットとソースコードを連携せよ！ (1/3)

ソフト/Bug Tracking/trac/TortoiseSVNやSubclipseとチケットを連動 - discypus

TortoiseSVNとITS・BTSの連携 S.S.S. blog/ウェブリブログ

redMine で trac の trac-post-commit-hook のような事をやる

バージョン管理システムとの連携 | Redmine.JP

TortoiseSVNのようなSVNクライアントには、pre-commitとpost-commitの機能が元々付いている。
pre-commitは、コミット前にコミットログの中身を精査してコーディング規約に合致しているかどうかチェックする。もしエラーならコミットできない。
post-commitは、コミット後に付与された内容を実現する。よくある例は、コミットログにチケットNoが書かれていれば、BTSのチケット画面にSVNリビジョンとコミットログを表示する。

pre-commitの使い道は、コミットログにチケットNoが書かれていなければ、コミット不可にすること。
この運用ルールは「No Ticket, No Commit」と呼ばれる。
このルールによって、SVNリビジョンとチケットの相互リンクが実現されるので、最終的にはビルドモジュールからチケットに書かれた修正理由へ追跡できるし、逆に過去のチケットから修正されたソース一覧を洗い出せるので仕様変更の影響範囲や同類バグ調査に使える。

つまり、チケットと成果物を紐づけることによって、トレーサビリティを実現できる。
このトレーサビリティは従来の開発プロセスやAgile開発には現れなかった性質であり、とても重要なポイントだ。

post-commitの応用としては、コミットログにチケットNoだけでなく特定のキーワードによってチケットの状態を更新出来ること。
Redmineの場合、「refs #1」ならチケット#1とリンクするだけだが、「fixes #2」ならチケット#2の進捗率＝100％にして更に解決済みステータスへ更新してくれる。
複数回のコミットはrefs、最終コミットはfixesと使い分ければ、開発者はチケットを逐一更新しなくてもコミット時に勝手にチケットの担当が終了したことになる。
この運用ルールに開発者が一度慣れると、コミットするのが楽しくなってくる。

SVNもCVSでも、pre-commit-hookやpost-commit-hookのスクリプトを書けば、ユーザはコミット時に意識する必要はない。
この手法はおそらくTracで普及し、RedmineではWeb画面から設定できるので便利になった。
今では、MercurialやGitでも、RedmineやTrac上で同様の操作が可能だ。

ITSが構成管理ツールと連携している利点は、単にITSの画面からSCMリポジトリを見れるだけでなく、pre-commit-hookとpost-commit-hookによって、チケットとSCMリビジョンがリンクされて、チケットに成果物の履歴が残り、トレースしやすくなることだ。

この特徴こそが従来のバグ管理システムには無かったものであり、チケット駆動開発へ発展していったきっかけになったのだと思う。
実際、チケット駆動開発では、ITSバージョンとリリース予定バージョンとイテレーションが対応づけられることによって、自然に小規模リリースを実現できる。
又、ITSプロジェクトとSCMコードラインとビルドモジュールが対応付けられることによって、メインラインモデルのタスク管理が楽になるので、派生開発や製品ファミリー開発を強力にサポートできる。

ITSと構成管理ツールとの連携については更に考察してみたい。