RedmineとHudsonの関係付け

Redmineのチケットとバージョン管理を連携できる機能は、変更管理のインフラを提供してくれる。
変更管理について考えたメモ書き。

【元ネタ】
PERFORCE ソフトウェア構成管理の高度な実践方法（ベストプラクティス）

【1】変更管理が必要な場面

SEと呼ばれる人の仕事を眺めてみると、要件や仕様に関する変更管理プロセスに従事している時が多いことに気付く。
SEの一番の仕事は、顧客から要件を聞き取り、仕様書としてまとめて、開発者へ仕様を提示する。
つまり、業務のインターフェイスを設計すること。

設計工程で完璧な仕様書が作られる可能性は低い。
むしろ、要件漏れ、設計漏れが開発や結合テスト、あるいは受入テストで大きなリスクとして発覚することが多い。

昨今のシステム開発では、SeasarやRailsのような優れたフレームワークがあり、JUnitのようなテストユニットがあるので、単体テストをクリアした品質は確保できる。
しかし、肝心の仕様書が高い品質で開発者へ提示されるという仮定がそもそも間違っている時が多い。
だから、間違った設計書、低品質な仕様書を元にプログラムを作るから、当然、顧客の要望とずれたシステムが出来上がってしまう。
プログラマよりも設計者が作る成果物の品質の方がはるかに低い場合が、最近は多いように見られる。

仕様漏れが発生する理由の一つは、実際にプログラムを組んで動かしてみないと分からない部分がSW開発では多いから。
だから、アジャイル開発のようにインクリメンタル型開発では、小さく作って小刻みにリリースして、問題を早めに嗅ぎ取ろうとする。

他の原因として、たった一つの要望や仕様変更で影響を受ける機能はどれか、提示された仕様はシステムに確実に反映されているのか、という調査やその設計が不十分な時が多いように思う。
昨今の業務系Webシステムは、数万行に膨れ上がっているから、わずか1行のソース変更でシステムに影響を及ぼす可能性があるから、細心の注意を払う必要がある。
また、保守されていない仕様書がExcelで散在しているならば、稼働中のシステムにある機能の詳細な一覧を探すことすら難しいだろう。

稼働中のシステムにバグがあったとしても、顧客はバグありの運用をしている時が多い。
たとえバグがあっても、動いているシステムの方が、リアルタイムに保守されない仕様書よりも正しいのだ。

設計者は、ソースから仕様をリバースして設計するようになるが、この時に、過去のパッチの変更理由、モジュールのビルド履歴、ChangeLogがあると非常に役立つ。
パッチの変更理由を元に、仕様変更で影響を受けるかどうか、判断を下す材料になる。

【2】チケットトラッキング機能

Redmineでは、チケットとSVNリビジョンを紐付ける機能があり管理画面で簡単に設定できる。
SVNコミット時に「refs チケットNo」「fixes チケットNo」「#チケットNo」をログへ追記すると、リポジトリブラウザからチケットへ遷移できる。
更には、チケットから、チケットに関する修正を受けたSVNリビジョン全てがリンクされている。

この機能のおかげで「ソースAの過去の修正で影響されたソースはどれか？」を探すことができる。
下記のような流れになるだろう。

【Subversion→Redmine→Subversion】
ソースAのコミット履歴を全て洗い出す
↓
コミット履歴から全てのチケットを洗い出す
↓
チケットから全てのSVNリビジョンを洗い出す
↓
SVNリビジョンからコミットされた全ソースを洗い出す

Redmineでは上記の作業を画面上で見て操作するか、全文検索で洗い出すだろう。
少なくとも、ソースのコミット履歴から、過去にどんな仕様でソースが影響を受けたのか、チケットから調べることができる。

RedmineのDBは上手に運用すれば、要件や仕様も蓄積されるから、いつでも全文検索の対象となる。
Excelに書かれた仕様よりも、DBにある方がはるかに探しやすいメリットがある。

【3】ビルド履歴との連携機能

Redmineのプラグインsimple_ciを使うと、ビルドツールと連携することができる。
ビルドツールとBTSを連携するメリットは「バグXの修正はビルドYにあるか？」という質問にすぐに回答できるインフラを提供してくれるから。

このインフラがあると、結合テスト以降のバグ修正で大きな威力を発揮する。
特に、デグレが起きていないかチェックするのに効果的だ。

Redmine - PluginSimpleCI - Redmine

但し、Hudsonのビルド履歴をRSSリンクする場合に、Rubyのsimple-rssモジュールをrequireしないと動作しない。
下記のパッチを反映すると、Redmineのsimple_ciタブにHudsonのビルド履歴が表示されるようになる。

Hudson support for simple_ci

Redmine - Feature #2163: Hudson Plugin - Redmine

また、HudsonでもRedmineプラグインが下記でリリースされている。
Hudsonのビルド履歴には、ビルドに取り込まれたSVNリビジョンのコミットログが表示されている。
このプラグインで、ビルド履歴に書かれたRedmineチケットがリンクされるので、Redmineへ相互リンク可能になる。
日本人作者の方に感謝！

Hudson Redmine plugin 0.6 - @Inject

Redmine Plugin - hudson - Hudson Wiki

上記の使い方は下記になるだろう。

【Redmine→Hudson】
Redmineのsimple_ciタブでHudsonの直近のビルド履歴を表示
↓
Hudsonのビルド番号のリンク押下
↓
Hudsonの該当ビルド番号の画面に、ビルドに取り込まれたコミットログ全てを表示

【Hudson→Redmine】
Hudsonのビルド番号の画面を表示
↓
表示されたコミットログにあるチケットNoのリンク押下
↓
Redmineチケットを表示
↓
Redmineチケットに表示されているSVNリビジョンから該当リビジョンを探す

ITILの講義を聞いた時、昔は問題管理に力点を置いていたが、昨今は構成管理や変更管理が重視される傾向がある、という話があった。
バグ管理システムRedmineと常時統合ビルドツールHudsonを組み合わせれば、変更管理の強力なインフラになりうる。