リリース履歴の重要性

Redmineには、変更履歴と言うリリース履歴の機能がある。
この機能がいかに重要か、ラフなメモ書き。

【1】チケット駆動開発では、バージョンをリリースしたら、自然にリリース履歴が残る。
SVNコミットに必ずチケットをリンクさせれば、終了チケットがリリース履歴になる。

リリース履歴は何故重要か？
いつ何をリリースしたのか、という記録だから。
手作業でリリース履歴を作ろうとすると作業漏れがおきやすい。

RedmineのようなBTS、Hudsonのようなビルドツールを使っていないチームでは、リリース履歴を自動作成することができないので、リリース履歴をExcelのリリース台帳で管理しているだろう。
例えば、開発者が修正したソースにタグを付けてリリース台帳に記載して、ライブラリアンはリリース台帳を見てビルド＆デプロイを実施するワークフローにしているだろう。

このワークフローはExcelのリリース台帳が一番重要。
このリリース台帳が壊れたり紛失したら、リリース作業に大きな支障を残す。
また、手作業のワークフローが多いので、ミスも多いだろう。

RedmineやMantisでは、ロードマップというリリース計画にチケットを一覧表示できるし、リリース予定バージョンでチケットをグループ化しておくと、先の予定のリリース作業が見えやすくなる。
そして、リリースしたバージョンの履歴が変更履歴として残るので、どのバージョンでどんなバグ修正を取り込んだのか、すぐに分かる。
つまり、BTSがリリース履歴を一括管理していることになる。

Hudsonの場合、RedmineやTrac、MantisなどのBTSと連携する機能がある。
実際、Hudsonがつけたビルド番号に、SVNリビジョンがひもづけられている。
そして、SVNのコミットコメントにチケットNoがあれば、Hudsonのビルド番号とリンクされる。
これによって、Hudsonでビルドしたモジュールに反映されたチケットを探すことができる。
これがトレーサビリティに当たる。

この機能があるからこそ、ビルドモジュールからSVNリビジョン、チケットを経由して、仕様や要件まで辿ることができる。

また、BTSで管理していれば、全文検索が可能だから、キーワードで検索できる。
従って、運用保守で、過去のパッチの修正意図を過去の終了チケットから探り出し、リバースエンジニアリングすることも可能。

【2】WF開発でも、設計工程のタスク管理にチケット駆動開発を使うと良い。
設計書は必ずSVNにコミットして、SVNの配下に置く。
つまり、設計書もバージョンアップしていく対象と捉える。

設計書の修正は必ずチケットを起票して、チケットに作業履歴を残す。
そうすれば、チケットとSVNリビジョンの関係を通じて、設計書とチケットが結びつく。

バージョンをマイルストーン単位にする。
マイルストーンは、設計書の提出時期、進捗報告の単位になる。

変更履歴に、マイルストーン単位の作業履歴が残る。
いつ誰が、どんな仕様を設計書に反映したのか、作業履歴が残る。
だから、何故こんな仕様が反映されたのか、後日になって検索して調査することも楽になる。

実際の設計書は、顧客から引き出した曖昧な要件を試行錯誤して詳細化しならが作られていく。
たくさんの課題を各チケットに起票しながら、そのチケットを解決する度に設計書をバージョンアップしていく。
たくさんのチケットを課題としてあげて、そのチケットを解決するほど、自然により良い設計になってくる。
ソースがたくさんのパッチで成長するように、設計書もたくさんの課題を反映することでより緻密になっていく。

リリース履歴には、構成管理の配下にある成果物の作業履歴であり、成長した履歴でもあるのだ。