Redmine・HudsonとSCMの機能の関連表 #itsjp #tidd

Redmine・HudsonとSCMの機能の関連表 をチケット管理システムWikiに追加した。

【元ネタ】
チケット管理システムWiki

RedmineとSCMの機能の関連表～BTSとSW構成管理の密接な関係 #itsjp #tidd: プログラマの思索

特集：Hudsonを使ったアジャイルな開発入門｜gihyo.jp … 技術評論社

CIツールHudsonを使いこなす: プログラマの思索

言いたかったことは、RedmineがSCM(構成管理)と密接に関係するだけでなく、ビルド管理ツールHudsonの機能とも対応していることだ。
つまり、下記の機能がそれぞれ対応する。

【1】SCMコードライン⇔Redmineプロジェクト⇔Hudsonジョブ

バージョン管理(Subversion、CVS、Git etc.)のリポジトリにあるtrunkやbranch単位で、ビルドモジュール(コンポーネント)が作られる。
Hudsonがビルドする作業の単位はジョブになる。
ビルドモジュールが複数個のコンポーネントを統合してビルドされる場合、下流ジョブにコンポーネント、上流ジョブにビルドモジュールというジョブの依存関係を設定する。

Hudsonを使ったアジャイルな開発入門：第3回　Hudsonによるチーム間の連携～上流・下流ビルド｜gihyo.jp … 技術評論社

上流・下流ビルド(ジョブ)とは、依存関係のある複数のジョブでつけるHudsonの機能。
普通は、jarのような最小のコンポーネントを下流ジョブとして先にビルドした後に、warのように最後にビルドするモジュールを下流ジョブとしてビルドする。
つまり、ビルドの実行順序を上流・下流ビルド(ジョブ)で関係付ける。

Hudsonが無かった頃は、Antなどで手作業でビルドしていたから、ビルドの実行順序を間違うとすぐにコンパイルエラーになってしまう。
Hudsonがあるおかげで、複雑なビルドもGUI上で設定できて、かなり楽になった。

更に、ビルドモジュールを本番環境へリリースする場合、ビルドモジュールが本当に本番モジュールであるのか、を検証したいなら、ファイル指紋を使えばいい。
ファイル指紋はバイナリファイルのハッシュ(MD5)であり、ファイル指紋を比較することでより厳格にリリース管理を運用することも可能。

Hudsonを使ったアジャイルな開発入門：第3回　Hudsonによるチーム間の連携～ファイル指紋を記録｜gihyo.jp … 技術評論社

【2】SCMタグ⇔Redmineバージョン⇔Hudsonビルド番号

Subversion(CVS) tagging pluginを使うと、SVN(CVS)タグからチェックアウトされたソースからビルドされる。
SVNタグをリリース予定バージョンとして厳格に扱う場合に有効。

HudsonのSubversion Tagging Plugin: プログラマの思索

イテレーションに紐づく全てのタスクが100％で終了したら、いつでもリリースできる。
SVN(CVS)タグはリリース予定バージョンであり、Agile開発ではイテレーションに相当する。

【3】SCMリビジョン⇔Redmineチケット⇔Hudsonビルドログ

SVNリビジョンに書かれたコミットログは、Hudsonのビルドログ(コンソールログ)に出力される。

RedmineとHudsonの関係付け: プログラマの思索

HudsonのRedmine(Trac, Mantis etc) pluginを使えば、Hudsonのビルドログから各BTSチケットへ遷移できる。
又、RedmineのHudson pluginを使うと、RedmineチケットのSVNリビジョンの履歴に「SUCCESS」「FAILURE」などのビルド結果が追記されるので、どのビルド番号にどのリビジョンが反映されているのか、が一目で分かる。

r-rabsのRedmine Hudson Pluginがすばらしい件

Redmine - Hudson Plugin 0.1.0 - Redmine

つまり、ビルドモジュール→SVNリビジョン→チケット←仕様(要件) or ビルドモジュール→BTSバージョン(SVNタグ)→終了チケット　というトレーサビリティを実現できる。

Redmineプロジェクトとビルドモジュールを対応づける理由の一つは、ビルドモジュールのリリース計画や変更履歴がRedmineプロジェクトのロードマップや変更履歴に対応するようにしたいからだ。
そうすれば、Redmineの各プロジェクトのロードマップを見るだけで、コンポーネントがいつどんな修正を反映してリリースされるのか、をすぐに一覧できる。

ソフトウェア開発のリリース管理では「いつ何をリリースするのか」「今のモジュールにどんな修正が反映されているのか」という2点がいつも重要になる。
しかしながら、リリース作業をきちんと記録して、厳格なワークフロー管理をしていないチームでは、デグレやリリース作業ミスが多発しがちで、開発メンバーのモチベーションを落としてしまう。
デグレやリリースミスほど、ソフトウェア開発で嫌なものは無い。

チケット駆動開発は、「いつ何をリリースするのか」はロードマップというリリース計画、「今のモジュールにどんな修正が反映されているのか」は変更履歴という過去のリリース履歴という機能に置き換える。
この2つの機能は、とても重要な意味を持っていると感じている。