Subversion（サブバージョン）は、設計書やプログラムのバージョン管理を行うための無料ツールです。
ただ、Subversionを使った最適な構成管理のやり方を認識する人は、意外に少ないかも知れません。
当記事では、Subversionを使った構成管理の実践的なやり方を解説します。
Subversionの「branches」、「trunk」、「tags」それぞれの役割
Subversionをインストールすると、まずは「trunk」、「branches」、「tags」という3つのディレクトリを作ります。
「trunk」、「branches」、「tags」の使い方はプロジェクトや人によって異なりますが、当記事では、それぞれの役割を下記の通り定義しました。
定義の目的は、成果物の「作成中」、「レビュー中」、「完成」という各フェーズを、Subversionの「branches」、「trunk」、「tags」を使って明確に分別することです。
成果物作成の流れに沿ったSubversionの使い方
成果物の作成状態によって、下記の通り保管場所を移動します。
- branches
- trunk
- tags
作成途中の成果物を保管
レビュー中の成果物を保管
完成済みの成果物を保管
「branches」（ブランチ）の役割
「branches」は、「レビューが可能となる前の段階で、作成途中の成果物を保管する場所」とします。
従って、開発担当者はセルフレビューが完了した段階で成果物を「trunk」へ移動します。
なお、本来、作成途中の成果物を保管する最適な場所は「branches」でなく、「共有できるサーバのディスク上」です。
理由は、作成途中の成果物は何度もSubversionへコミットされるため、コミットの度にファイルがSubversionのディスク領域へ保存されます。コミットによって保存されたファイルは消えないため、Subversionのディスク領域が足りなくなる懸念が出てきます。
従って、過去履歴のファイルを残さずファイルを全員で共有できる「共有できるサーバのディスク上」が理想的という訳です。
「trunk」（トランク）の役割
「trunk」は、「レビューが可能となった作成中の成果物を保管する場所」とします。
レビューと指摘反映を繰り返してる間は、成果物に版を付与することで成果物のレビュー状態が分かるようにして、全てのレビューが完了した時点で「tags」へ保管場所を移動します。
「tags」（タグス）の役割
「tags」は、「完成済みの成果物を保管する場所」とします。
完成済み成果物を保管した後に修正した場合にも、修正済み成果物となった段階で上書き保存します。要するに、常に最新状態に保つことが大切です。
スポンサーリンク
Subversionを使った構成管理の流れ
Subversionを使った構成管理の実践的な流れを解説します。
プロジェクト計画段階
プロジェクト計画段階でSubversionを立ち上げて整備することが構成管理をし易くするため、非常に重要です。
1.プロジェクト発足と共にSubversionのbranches、trunk、tagsを整備
成果物を保管する前に、branches、trunk、tags配下のディレクトリ構造を整備しておくと、各担当者が好き勝手にディレクトリを作るリスクが軽減されます。
ディレクトリ構造は、誰が見ても目的の成果物を探し出せることを目標にして構築します。
プロジェクト進行中
プロジェクト進行中は、ルールに沿ってSubversionに成果物を保管させることが重要です。
2.branchesに成果物を保管して成果物を作成
各開発担当者は、作成中の成果物をbranches配下のディレクトリに保管して開発を進めます。
3.作成した成果物をtrunkへ移動してレビューを開始
成果物がレビューできる段階となった状態で、成果物をtrunk配下のディレクトリに保管し直します。
trunk配下に保管した成果物は、branches配下から削除します。誤ってbranches配下の成果物を更新しないようにするためです。
4.レビュー完了、又は客先承認を以て成果物を1.0版として成果物マスタへの登録を申請
チーム内、もしくは客先レビュー指摘を全て反映し終わるまでは、成果物をtrunk配下に保管します。
成果物は、チーム内、もしくは客先の承認を以て1.0版とします。
1.0版となった成果物をtags配下の「成果物マスタ」へ登録するため、ライブラリ管理者へ「払戻申請」を行います。
なお、tags配下への保管や参照は、ライブラリ管理者のみが行います。
5.ライブラリ管理者が成果物マスタへ保管
払戻申請が承認されると、ライブラリ管理者が1.0版の成果物を「成果物マスタ」へ保管します。
「成果物マスタ」へ登録された段階で、trunk配下の成果物は削除します。
また、「成果物マスタ」へ登録された以降に成果物を修正したい場合、開発担当者はライブラリ管理者へ「払出申請」を行い、ライブラリ管理者が「成果物マスタ」からコピーした成果物に対してのみ修正します。
この理由は、「成果物マスタ」の成果物が最新であるためと、誤って手元に保管した1.0版では無い成果物に修正を加えて先祖返りすることを防止するためです。
6.（プログラムの場合）総合テストを成果物マスタから払い戻したプログラムを使って実施
総合テストのテスト環境は、全て「成果物マスタ」に保管されるプログラムを使って構築します。
この理由は、「成果物マスタ」へ登録されるプログラムが正しいことを証明するためです。
7.（プログラムの場合）総合テストの修正版を成果物マスタへ再保管
万一、総合テストで不具合が発生したり、「成果物マスタ」への登録漏れが発生した場合、開発担当者はライブラリ管理者へ「払出申請」を行い、プログラムを修正後に「払戻申請」で「成果物マスタ」へ最新プログラムを再保管します。
納品時
全成果物が成果物マスタに登録された後、全成果物を納品する時に行う手順です。
8.成果物マスタに1.0版の全成果物が揃った段階で「tags/リリース/」へ成果物マスタの全成果物をコピー
成果物マスタに1.0版が揃った成果物を納品することから、納品物として「tags/リリース/」へ全成果物をコピーします。
成果物マスタは今後も更新される可能性があるため、1.0版より版が上がった版を誤って納品しないよう、1.0版のみを別ディレクトリへ保管することを目的としています。
9.「tags/リリース/」の成果物を使って納品作業を開始
1.0版のみ揃った成果物を使って、納品作業を開始します。
「branches」、「trunk」、「tags」の実践的な使い方
「branches」、「trunk」、「tags」の実践的な使い方を解説します。
「branches」（ブランチ）の使い方
「branches」は、「レビューが可能となる前の段階で、作成途中の成果物を保管する場所」であるため、「branches」の下に作るディレクトリ名は「成果物名」が分かりやすいと思います。
なお、「担当者名」や「チーム名」をディレクトリ名に付与することは厳禁です。人やチーム名が変わった時、ディレクトリに保管される成果物が分かりづらくなるためです。
branches/会議資料
branches/要件定義書
branches/基本設計書
・
・
branches/プログラムソース
「trunk」（トランク）の使い方
「trunk」は、「作成中の成果物を保管する場所」であるため、「branches」と同じディレクトリ構造を「trunk」の下に作ると分かりやすくなります。
レビューできる状態となった成果物を、「branches」から「trunk」へそのまま移動します。「trunk」へ移動した段階で「branches」の成果物を削除すると、誤って「branches」の成果物を編集するミスを防止できます。
「branches」から「trunk」へ移動した段階で、成果物は「0.70版」という版を成果物のファイル名に付与します。そして、第1回レビューが完了して指摘反映した版は「0.71版」とします。
版管理の具体的な考え方は後述します。
trunk/会議資料
trunk/要件定義書
trunk/基本設計書
・
・
trunk/プログラムソース
「tags」（タグス）の使い方
「tags」は、「完成済みの成果物を保管する場所」であるため、下記2通りのフォルダを作って完成済みの成果物を保管します。
なお、「tags」の成果物は完成品であるために担当者は触ることができず、ライブラリ管理者のみ操作できるルールとします。
完成済み最新の成果物だけを保管する「成果物マスタ」
「成果物マスタ」とは、最新版の成果物（設計書、プログラム等）を管理するディレクトリです。
開発担当者が直接インポートすることは厳禁で、必ず開発担当者はライブラリ管理者へ申請して、ライブラリ管理者のみ直接「成果物マスタ」の追加、更新及び削除ができます。
開発担当者が「成果物マスタ」に保管される設計書を使って次の開発を行う場合、ライブラリ管理者に対して「払戻申請」を行い、ライブラリ管理者が「成果物マスタ」から設計書をエクスポートして、開発担当者へ渡す流れです。
次の開発のベースラインは「成果物マスタ」に保管している設計書やプログラムであるため、次の開発（改造案件）に使う設計書やプログラムは「成果物マスタ」に保管された設計書やプログラムを使います。
例えば、自分の手元に保管している設計書やプログラムを次の開発に使ってはいけません。
次の開発（改造案件）で完成した設計書やプログラムは、開発担当者がライブラリ管理者へ申請して、「成果物マスタ」への登録をしてもらいます。申請を受けたライブラリ管理者は、「成果物マスタ」へ受け取った設計書やプログラムのファイルを上書き保存します。
・成果物マスタを作る（「trunk」とは別フォルダとして開発者の目になるべく触れないため）
→チェックアウト申請、又はチェックイン申請無しにファイルの追加、更新、削除はできない
完成済みでリリース時点の成果物をリリース単位で纏めて保管する「リリース」フォルダ
「成果物マスタ」は最新状態の成果物を保管するのに対して、「リリース」フォルダは「リリース時点のバージョンを纏めて保管する」フォルダです。
このフォルダに全成果物を保管する目的は、「各リリースのタイミングで納品する成果物の状態で保管」することです。
例えば、10月に本稼働後、3ヵ月単位でリリースするなら、「tags/リリース」には下記のようなフォルダが作られます。
tags/成果物マスタ/
tags/リリース/201910本稼働/
tags/リリース/202001リリース/
tags/リリース/202004リリース/
・
・
上記のリリースフォルダに保管する対象のファイルは、成果物マスタに保管される全成果物をコピーします。
この理由は、下記のような事例発生への対策としてです。
- 更新されたファイルだけを成果物マスタから抽出して保管すると、抽出漏れが発生する可能性があるため
- リリースに失敗した際、前にリリースしたプログラムへ全て戻せるようにするため
- リリースで不具合が発生した際、当該リリース時に未更新のファイルも含めて原因調査を行うため
- 本来、更新されたファイルをリリースする予定が、誤って未更新のファイルがリリースされていたことを発見するため
なお、tags/リリース/に保管したプログラムに不具合があっても、tags/リリース/に一旦保管したプログラムは入れ替えません。不具合修正したプログラムは「成果物マスタ」へのみ反映して、次の開発も「成果物マスタ」に保管されたプログラムを改造します。
Subversionで管理する成果物の版管理の事例
Subversionで管理する成果物に、版のルールを設けて管理すると、成果物の状態が把握できます。
具体的な版管理の事例を紹介します。
0.70版は作成者のセルフレビュー完了
0.70版は、作成者のセルフレビューが完了して、レビューアとのレビューができる状態を表します。
Subversionのtrunkには、0.70版から新規登録します。
レビューアからの指摘を全て反映する度に0.71版と0.01ずつカウントアップして、trunkに保管し直します。
0.80版は客先説明が可能な状態
0.7x版で指摘反映が全て完了した版は、客先提出が可能な状態であるため0.80版とします。
客先からの指摘を全て反映する度に0.81版と0.01ずつカウントアップして、trunkに保管し直します。
なお、客先からの指摘が無かった場合は0.90版とせずに1.0版（完成版）とします。
0.90版は客先指摘を全て反映
客先との打合せで受けた指摘を反映した版は0.90版とします。
客先へ0.90版を提出して、客先承認を得られた段階で1.0版とします。
客先からさらに指摘があり、その指摘を全て反映する度に0.91版と0.01ずつカウントアップして、trunkに保管し直します。
1.0版は客先承認済み、もしくは完成済み成果物
客先からの指摘を全て反映済みで、完成版として客先から承認を得られた版は1.0版とします。
なお、客先承認が不要な成果物は、レビュー指摘が全て反映されて承認者の承認が得られた段階で1.0版とします。
1.0版となった成果物はライブラリ管理者へ申請して、Subversionのtagsにある「成果物マスタ」へ保管します。
Subversionに作成するディレクトリ構造の事例
Subversionに作成するディレクトリ構造を事例で紹介します。ディレクトリ構造が整理されると、開発担当者の誰もが成果物を発見し易くなります。
trunk配下のディレクトリ構造の事例
下記はtrunk配下のディレクトリ構造を一例として挙げています。なお、branchesも同じディレクトリ構造にすると誰が見ても分かりやすくなります。
trunk/会議資料/A会議/
/A会議/議事録/
/B会議/
/B会議/議事録/
/要件定義書/A要件定義書/
/B要件定義書/
/基本設計書/A基本設計書/
/B基本設計書/
/詳細設計書/A詳細設計書/
/B詳細設計書/
/プログラムソース、モジュール/HTML/
/scr/
/単体テスト仕様書兼成績書/
/結合テスト仕様書兼成績書/
/結合テストデータ/
/総合テスト仕様書兼成績書/
/総合テストデータ/
/ユーザ検証テスト仕様書兼成績書/
/ユーザ検証テストデータ/
/運用手順書/
/保守手順書/
/操作説明書/
tags配下のディレクトリ構造の事例
tasg配下は「成果物マスタ」フォルダと「リリース」フォルダを作成しますが、成果物マスタには会議資料等は入れず、設計書、プログラム並びに操作説明書等、今後の開発でも使用される可能性がある成果物のみを保管します。
tags/成果物マスタ/要件定義書/A要件定義書/
/B要件定義書/
/基本設計書/A基本設計書/
/B基本設計書/
・
・
/リリース/201910本稼働/会議資料/A会議/
/A会議/議事録/
/B会議/
/B会議/議事録/
/要件定義書/A要件定義書/
/B要件定義書/
/基本設計書/A基本設計書/
/B基本設計書/
・
・
/202001リリース/会議資料/A会議/
/A会議/議事録/
/B会議/
/B会議/議事録/
/要件定義書/A要件定義書/
/B要件定義書/
/基本設計書/A基本設計書/
/B基本設計書/
・
・
/202004リリース/会議資料/A会議/
/A会議/議事録/
/B会議/
/B会議/議事録/
/要件定義書/A要件定義書/
/B要件定義書/
/基本設計書/A基本設計書/
/B基本設計書/
・
・
