チケット駆動開発がもたらした新しい観点part2～トレーサビリティの拡張

Redmine・Trac・Mantisでチケット駆動開発を実践してみて、技術的に一番面白いのは、ツールの連携によるトレーサビリティの強化であり、その拡張だ。
この考え方は「ソフトウェア構成管理とはそもそも何なのか？」という問題に行き着くと思う。
以下ラフなメモ書き。

【1】チケット駆動開発の基本的な運用ルールは「No Ticket, No Commit!」だ。
実際の運用方法は、SVNやGit、Mercurialのコミットログに「refs #チケットNo」「fixes #チケットNo」を付けてcommitすると、自動的にチケットとリビジョンが相互リンクするやり方。

この運用ルールは、障害管理において、障害報告票に基づいてどのようにソースが修正されたのかをレビューしたり検証したり、リリース後に確認できるようにしたい発想から生まれた。
この単純な運用ルールこそが、従来のAgile開発には無かった強力なトレーサビリティによる変更管理を実現してくれる。
つまり、ソフトウェア開発全般の作業において、ソースだけでなく、バージョン管理のリポジトリにある全ての成果物の変更履歴がチケットに記録されることによって、何故こんな汚いパッチが過去に実施されたのか、何故こんな複雑な仕様に行き着いたのか、などの理由を追跡できるようになる。

【2】チケット駆動開発の本来のトレーサビリティは、バージョン管理のリビジョン単位のソースや設計書の変更管理だ。
チケット駆動開発を実践してみて、このトレーサビリティを拡張した考え方は二つある。
一つは、ITSチケットだけでなくITSのプロジェクト、バージョンにもバージョン管理の概念を対応付けること。
もう一つは、CIツールの機能にトレーサビリティの概念を対応付けること。

前者は、下記のWikiに書いた。
RedmineとSCMの機能の関連表～BTSとSW構成管理の密接な関係 #itsjp #tidd: プログラマの思索

つまり、ITSチケットとSCMリビジョン、ITSバージョン(マイルストーン)とSCMのタグ(リリースバージョン)、ITSプロジェクトとビルドモジュール(製品)の3種類に対応付けることができる。
ITSのバージョン(マイルストーン)とSCMのタグ(リリースバージョン)を対応付けるだけでなく、アジャイル開発のイテレーション(スプリント)に対応付ければ、自然に小規模リリースを実現できる。

ITSプロジェクトとビルドモジュールを対応付けることは、例えばRedmineの設計思想において、1プロジェクト＝1リポジトリであることから必然だ。
この対応関係によって、バージョン管理のリポジトリにある成果物の全ての変更作業は、対応するITSプロジェクトのいずれかのチケットに必ず起票され、記録される。
すなわち、バージョン管理のリポジトリからビルドされてリリースされるモジュール(製品)に関する作業履歴は、対応するITSプロジェクトのいずれかのチケットに必ず記録されている。
だから、製品のリリース履歴がITSのロードマップに自然に対応付けられ、そのロードマップこそが製品の今後の開発の方向性をユーザに提示するものになる。

後者は下記のWikiに書いた。
Redmine・HudsonとSCMの機能の関連表 #itsjp #tidd: プログラマの思索

HudsonやJenkinsには、Redmine・Trac・MantisなどのBTS/ITSと連携するプラグインが提供されているので、それらITSに紐づくバージョン管理のコミットログをCIツールのビルドログと関係付けることができる。
この性質によって、どのビルドモジュールにどんなソースの修正が入っているのか、を確認出来る仕組みができあがる。
つまり、ビルドモジュールのビルドNoからSCMリビジョン、ITSチケットを経由することで本来の要件や仕様まで辿ることができる。

また、HudsonやJenkinsにはSubversion(CVS) Tagging pluginがあり、これを使うと、指定したTagをチェックアウトしてビルドする作業が簡単になる。
すなわち、SCMタグをビルドモジュールのリリースバージョンに厳格に対応付けることが可能なことを意味する。
更に、ビルドモジュールのリリース予定バージョンは、ITSのロードマップに書かれたバージョン(マイルストーン)に一致するように運用すれば、バージョン単位の変更履歴を追跡することが楽になる。
どのバージョンが品質が安定しているのか、どのバージョンで仕様変更されたのか、を追跡するときに役立つだろう。

そして、CIツールのジョブをSCMリポジトリに対応付けるのは当たり前の作業。
これらの対応関係によって、CIツール・SCM・ITSが密接に連携できるようになり、ソフトウェア開発の3種の神器の概念を更に強化してくれる。

【3】トレーサビリティの概念が重要な理由は、変更管理や構成管理を実際に運用する時に使うからだ。
仕様を変更する時にきちんと手続きを経て決めたのか、修正履歴は必ず残されているか、をサポートするためにトレーサビリティが必要。

実際の修正履歴は、ITSチケットとSCMリビジョンの連携によって記録される。
だが変更管理で重要な概念はベースラインだ。
つまり、顧客や会社の上司など全てのステークホルダーが承認した時点の成果物のスナップショットがベースラインとして順次記録されていく。
このベースラインという概念は、Agile開発のイテレーション、システムのリリース済バージョン、SCMタグと同一視できるのがポイントだ。
そのアイデアについては以前書いた。

イテレーションはSW開発で何故重要なのか？: プログラマの思索

チケット駆動開発の本質はバージョン・ファースト: プログラマの思索

悪いウォーターフォル型開発では、工程がベースラインになっているため、手戻り作業が発生するともう一度過去の工程の作業にさかのぼらなくてはならない。
その時、ITSバージョンを工程単位(例：設計・開発・テストなど)に作っていると、過去にリリース済みのバージョンをReOpenして修正する羽目になってしまう。
だから、手戻り作業が発生する度にバージョンをReOpenしてしまい、いつまで経ってもどのバージョンもリリースできなくなる。
そもそもITSバージョンがベースラインと同一視されるならば、過去のベースラインを改ざんすることはシステム監査上ありえないはずだ。

逆にアジャイル開発では、イテレーションが終了したら、リリースしたモジュールの過去の履歴は触らず、次のイテレーションに向けて要件や作業を決めていく。
アジャイル開発ではイテレーションがベースラインに自然に同一視されるから、未来のベースラインに向けて機能改善を積み重ねていく。
これが本来のソフトウェア開発のあり方だと思う。

すると、ソフトウェア構成管理とは一体何なのか？という話になる。
ソフトウェア構成管理は単なるバージョン管理だけでなく、ソースや設計書の修正だけでなく要件や仕様の変更をコントロールする仕組みを提供するものであるはずだ。
そのアイデアについては下記に書いた。

構成管理、変更管理、プロジェクト管理の密接な関係: プログラマの思索

PerforceによるSW構成管理: プログラマの思索

ソフトウェア構成管理の定義はIEEEやCMMIに書かれているけれども、僕には何となくピンとこなかった。
その理由は、変更管理の実装方法がきちんと書かれていないために変更管理をイメージできていなかったからだと思う。
だからこそ、チケット駆動開発で構成管理や変更管理について色々試してみて、ようやく腑に落ちるものがあった。

但し、上記はあくまでも僕が経験した内容に過ぎず、もっと深い意味が隠れているのかもしれない。
色々考えてみたい。