ITエンジニアの業務効率を改善するために、現役エンジニアが実際の現場で利用している便利ツールを、10回にわたり紹介します。
普段無意識にやっているファイルの整理を、「Subversion」を使ってバージョン管理、構成管理します。このツールを使えば、開発チームの効率がアップすること間違いなしです!
バージョン管理というと、ソフトウェア構成管理のことを示す文章を見掛けますが、「CMMI」(Capability Maturity Model Integration:ソフトウェア開発におけるプロセスの成熟度評価やプロセス改善を行うためのガイドライン)のソフトウェア構成管理によると、「変更管理を含むソフトウェアの構成を制御・管理できていること」と定義されています。
今回は、ソフトウェアのソースコード管理だけでなく構成管理(ドキュメント管理)におけるSubversionの使い方を説明します。
一般的に、構成管理に必要な要素には、(1)バージョン管理、(2)ベースラインの管理、(3)変更管理の3つがあります。
(1)バージョン管理
管理対象の成果物はさまざまですが、多くは、ソースコードファイルやテストスクリプトファイルなどのテキストデータのみならず、WordやExcelなどの設計書、Power Pointの企画書などのバイナリファイルもあります。これらを「構成要素」と呼びます。
構成要素に対して、版管理(更新した履歴を世代管理)する機能のことを、一般的にはバージョン管理といいます。通常は一意の名称を付与して管理します。
Subversionなどの構成管理ソフトがない場合は、以下の例のように、ファイル名などを工夫して世代を管理していると思います。
(例)
1_企画書.ppt → 2_企画書.ppt → 3_企画書.ppt
設計書_V1.doc → 設計書_V2.doc → 設計書_V3.doc
20090814_設計書.doc → 20090815_設計書.doc → 20090816_設計書.doc
(2)ベースラインの管理
構成要素の版管理は、個々のファイルごとに実施され、ソフトウェアや設計書は複数のファイル群によって構成されていることが多々あります。その場合、個々のファイルのバージョンが、“ある時点”によって容易に抽出できることが重要です。
開発過程の“ある時点”で関係性を維持している状態のことを「ベースライン」と呼びます。このベースラインは進ちょくや達成を図る基準になっているといってもよいでしょう。
例えば、何も考えていなければ、企画書と設計書を図1のように管理していると思います。
お客さんに初めて提出したときは、共にバージョン1です。1回目の修正をしたときはバージョン2にして保存します。最後に提出修正したものをバージョン3にして保存します。とはいえ、すべてのファイルを毎回更新するようなことはないと思います。
図2では、お客さんに初めて提出したときのものが共にバージョン1です。1回目の修正で企画書だけ修正したとします。そのときは企画書をバージョン2にして保存します。最終提出として、微調整した企画書をバージョン3、設計書をバージョン2で保存します。
これを数回繰り返していると、お客さんに提出したバージョンのセット(企画書はバージョン3、設計書はバージョン2)がどれか分からなくなります。
うっかり企画書と設計書のバージョン2を出してしまったら、内容がおかしく、設計書として正しくなくなります。プログラムでいうと実行できない状態、つまり最悪の状態です。
このようなことをなくすために、少しだけ考え方を変えます。お客さんに提出したときにベースライン登録をするのです。そのとき、バージョンの付け方を変えるだけで、図3のように分かりやすくなります。
図3では、お客さんに初めて提出したときのものは共にバージョン1です。1回目は、企画書だけ修正しました。そのときは企画書をバージョン1.1にして保存します。最終提出物として微調整した企画書をバージョン2.0、設計書をバージョン2.0にして保存します。
これで、大きなバージョンがそろっているドキュメント同士を提出する仕組みができ、納品したすべてのファイルのバージョンを覚えておく必要がなくなります。
(3)変更管理
変更管理は、バージョン管理された構成要素に対する変更を管理するものです。
ソースファイルや設計書などのドキュメントは、必ず何かしらの理由があって変更されるものです。例えば、お客さんとのレビュー後の修正、仕様の変更、単純な間違いなどです。
構成管理では、個々の変更理由を漏れなく管理し、その変更理由に対する修正結果をバージョン管理する仕組みが重要です。これについては、後ほど差分のところで説明します。
Copyright © ITmedia, Inc. All Rights Reserved.