HOME 製品 PERFORCE 技術情報

新しいソフトウェア構成管理（SCM: Software Configuration Management）ツールを自社内に展開するとき、実装担当者は、しばしば詳細な活動まで完璧に行おうとする一方、これまでのまずい大規模なやり方を、知らず知らずに推し進めてしまいます。その結果として、大きな失敗を招いてしまいます。
ここでは、SCM展開における著者の経験に照らした、高度なSCM実践方法（ベストプラクティス）をご紹介します。

「道具は、それを使う人によって効果が変わる」とよく言われます。我々は、ソフトウェア構成管理（SCM）ツールの提供者、あるいはソフトウェア会社に対するコンサルタントとして、SCMのベストプラクティスについての適切なアドバイスをしばしば求められます。すなわち、「どのようにSCMソフトウェアを展開すれば最大の利益を得られるか」という内容のアドバイスです。このような要請に対し、我々は、直接的あるいは間接的な経験を豊富に持っています。直接的な経験とは、我々自身が開発者あるいはコードラインの管理者であることによるものであり、間接的な経験とは、我々の製品(Perforce)や他のSCMツールを使った顧客の成功／失敗事例によるものです。 以下の表には、SCM展開における6つの一般的なポイントがリストアップされています。そして、各ポイントの中で、ベストプラクティスに関する概略を示しています。 詳細については次章以降で説明します。

作業領域とは、開発者が自分達のソースファイルの編集、ソフトウェア・コンポーネントのビルド、そしてビルドしたもののテスト、デバッグを行う場所です。ほとんどのSCMシステムは、作業領域の概念を持っています。例えば、Source Integrityでは"sandboxes"、ClearCaseやPerforceでは"view"と呼ばれています。SCMのリポジトリで管理されたファイルを変更するという操作は、作業領域上のファイルを変更することから始まります。

作業領域に関するベストプラクティスは、次のようになります。

作業領域を共有しない。
作業領域の目的は、単一であるべきです。つまり、1人の開発者が編集／ビルド／テストする場所、もしくは製品リリースのためにビルド／テスト／リリースする場所であるべきです。作業領域の共有は作業机を共有するようなものであり、混乱を招きます。さらに、ユーザやタスク毎の履歴追跡という、SCMシステムの能力を損ないます。作業領域やディスクスペースは安価なものですので、作業領域を節約しようとして時間を浪費しないで下さい。

管理された作業領域外で作業を行わない。
SCMシステムは、管理された作業領域の中で起こる作業の進捗のみを追跡できます。作業領域の外で作業をしているユーザは、流れる情報の川岸に取り残されたようなものです。例えば、一般的にSCMシステムでは、関連作業に携わっている開発者間のコミュニケーションを容易にするために、作業領域を使用します。開発者は他の作業領域で起きたことを見ることができ、他の開発者たちはその開発者が行っていることを見ることができます。もし、その開発者が急な休暇をとらなければならなくなったとしても、適切に管理された作業領域ならば問題ありません。適切な作業領域を使うことが重要です。

「無秩序なview」を使わない。
作業領域にあるファイルに対し、明示的に変更する意思を持たない限り、そのファイルを変更すべきではありません。無秩序なviewとは、管理が及ばないところで起こる外部的なできごとによって、ファイルの変更が起きてしまう作業領域のことです。無秩序なviewの代表的な例は、他の作業領域中のファイルに対して、シンボリックリンクを持っている作業領域です。そのようなケースでシンボリックリンク先のファイルが更新されると、（シンボリックリンクである）自分のファイルが変更されたことになってしまいます。無秩序なviewは、ソフトウェア開発に混乱を引き起こす原因となります。例えば、実行ファイルの中のデバッグシンボルは、ソースファイルと合わなくなります。また、取るに足らないビルドでも、不必要なコンパイルが発生してしまいます。そして、デバッグのサイクルは、いつまでたっても収束しないでしょう。これらは、起こり得る問題のほんの一部です。ファイルがいつ変更されたかをユーザが管理できるように作業領域を設定することで、自分の作業領域を堅固かつ安定させるようにして下さい。

コードラインと同期する。
開発者としての作業の質は、他の開発者の作業とどれくらいかみ合うかに依存します。言い換えれば、変更されたコードラインがチェックインされたとき、開発者は作業領域を更新し、変更を統合すべきです。 構成管理者は、作業領域の更新手順を、簡単で手間のかからないものにする必要があります。作業領域の更新作業が、開発者にとって手間のかからないものであるとわかれば、より頻繁に更新が行われます。結果として、プロジェクトの締め切り時に、統合の問題が山積みになるということはなくなるでしょう。

頻繁にチェックインする。
複数の開発者で共同作業を行っている場合には、変更が確定し次第、その変更をチェックインする必要があります。開発作業が終了したら、他の開発者がその変更を認識できるように、その変更をチェックインして下さい。 繰り返しますが、構成管理者は、頻繁にチェックインできるような仕組みを作らなければなりません。必要以上に厳密な、妥当性の評価手順を実装してはいけません。そして、コードラインを凍結させてはいけません（「4.ブランチ」を参照）。短期的な凍結ならば許容範囲ですが、長期にわたる凍結は生産性を低下させ、変更されたコードラインのチェックインが遅れれば遅れるほど、それまでの多大な生産性が無駄になってしまいます。

本書におけるコードラインとは、ソフトウェア開発に必要な、基準となるソースファイルの集まりです。一般的に、コードラインは分岐してさまざまなバージョンのコードラインへと進化し、そのブランチは異なるリリースに盛り込まれます。これに基づいて、コードラインに関するベストプラクティスをまとめると、次のようになります。

それぞれのコードラインに方針を設定する。
コードラインに対する方針とは、コードラインに関する正当な使い方と、許可されるチェックインについて規定したものです。それは、コードラインに関するSCMのための基本的なユーザ・マニュアルになります。例えば、開発しているコードラインに対する方針では、そのコードラインがリリースのためのものでないことを明記しておくべきですし、同様にリリースするコードラインに対する方針では、承認されたバグ修正のみが行われるように制限しておくべきです。その方針にはまた、チェックインされている変更をどのように文書化するのか、どのようなレビューやテストが必要なのか、チェックイン後のコードの安定性に関する期待値はどのようなものか、などについても記述することができます。方針は、文書化され強制力を持った、ソフトウェア開発プロセスの重要な一部分となります。方針を持たないコードラインは、SCMの観点から見ると、制御を失っているに等しいと言えます。

それぞれのコードラインに（単にコーディングを行うだけではない）所有者を設定する。
いったんコードラインに対する方針を定義しても、間もなく、その方針を適用できない場面や、方針が曖昧になってしまうような特別な場面に遭遇することがあります。このような曖昧な場面に直面した（単にコーディングを行う）開発者は、回避策を求めてコードラインの所有者を頼ることになります。ところが、所有者が存在しないと、開発者は自ら取った回避策を文書化せずに、正規の手順としてしまう傾向があります。あるいは、開発者が適切な回避策を見つけるための十分な情報を持っていないために、この回避行動がとれなくて、ただ単に無駄な時だけが過ぎることになります。コードラインを所有し、コードラインに対して責任を持つ特定の人を決めることにより、このような窮地を脱することができます。以上のように目標をより高く設定することによって、コードラインの所有者は方針に対する例外事項について助言を行い、さらにその例外事項を文書化し、ソフトウェア開発における難局をスムーズに乗り切ることができるのです。

メインライン（主流となる開発経路）を持つようにする。
「メインライン」または「主幹」は、永久的に進化するコードラインのブランチです。メインラインは、ほとんどすべての変更に対する最終的な行き先になります。 ここで言う変更とは、メンテナンスによる修正と新しい機能追加の両方を指します。そして、このメインラインは、ソフトウェア製品の重要かつ着実な進化を表します。リリースされるコードラインと開発中のコードラインは、メインラインから分岐し、そのブランチの中で発生した作業はメインラインへ伝達されます。

図1 メインラインモデル

図1は、メインライン（"main"と呼ばれます）と、そのメインラインから分岐しているいくつかのリリースライン（"ver1"、"ver2"および"ver3"）や機能的な開発ライン（"projA"、"projB"、および"projC"）を示しています。開発者は、メインラインや開発ライン内で作業します。リリースラインには、テストや重大なバグ修正が待ち受けており、開発作業からは隔離されます。リリースラインや開発ラインに対して行われたあらゆる変更は、最終的にメインラインへマージされます。

別のアプローチとして、コードラインを「昇格させる」というアプローチがあります。例えば、開発ラインをリリースラインに昇格させ、新しい開発ラインをそこから分岐させるというものです。図2 は、ある開発ラインがリリースライン（"ver1"）に昇格し、そこから別の開発ライン（"projA"）が分岐している例です。各々のリリースラインは、開発ラインとして出発し、開発作業はコードラインから新規のコードラインへ次々と移動していきます。

図2 昇格モデル

この昇格のスキームには、2つの欠点があります。1つは、コードラインの方針を変更しなければならず、これをすべての開発者に伝えることは、決して容易ではないということです。もう1つは、開発者に対して、進行中の作業を別のコードライン内で行うように強いるということです。このことは、エラーを引き起こし易くし、時間の浪費にもつながります。実は、メインラインがないことを補完するためにコードラインの昇格を強いるケースが、SCM「プロセス」の 90%を占めています。

メインラインモデルを使用した場合、プロセスは合理的に簡素化されたものとなります。メインラインを用いることにより、開発者の作業領域と環境は、当面の開発作業の間、安定したものとなります。そして、ソフトウェア製品がそのライフサイクルの成熟期を迎えるまで、管理上のオーバヘッドがさらに発生することもありません。

ブランチ機能は、あるコードラインからバリエーションを作成するため、SCMでは最も問題となり易い部分になります。さまざまなSCMツールが、まったく異なる方法でブランチ機能をサポートしています。また、さまざまな方針により、さらに異なる方法でブランチ機能を使用する必要が生じます。以下は、ブランチ機能を使用するとき（または、使用を避けるとき）の有用なガイドラインです。

必要なときにのみブランチを使用する。
すべてのブランチは、作業の増加（ビルドの増加、コードライン間で伝達される変更の増加、ソースファイルのマージの増加）を引き起こします。ブランチしようとするとき、このことを常に意識することで、不必要なブランチの派生を防ぐことができます。

ブランチしようとするときに物理的なコピーをしない。
SCMツールのブランチ機能を使う代わりに、あるコードラインからソースファイルの集まりをコピーして、別のコードラインに新しいファイルとして保存する方法があります。コピーすることで、ブランチ機能を使用した場合のコストを回避できると考えてはいけません。コピーは、単にSCMツールのブランチ機能による利点がないというだけでなく、 ファイルの実体や管理情報の追加、複雑度の増加といった、ブランチ機能に絡む頭の痛い問題を、次から次へと引き起こします。「読取り専用」のコピーを、あくまでも「参照のみ」として別の開発グループに送ったとしても、編集されてしまうことがあります。コードラインの全部または一部を渡すときは、SCMツールを使用してブランチを作らなければなりません。

両立し得ない別々の方針に基づいてブランチする。
コードラインを分岐すべきかどうかを判断する際、1つの簡単な基準があります。すなわち、開発者が異なるチェックインの方針を必要としているときに、ブランチすべきだということです。例えば、製品リリースのグループでは、厳密なテストを強制するチェックインの方針を必要としますが、開発チームでは部分的にテスト済の変更部分を、頻繁にチェックインできる方針を必要とします。このように異なった方針を持つ場合、ブランチが必要となります。ある開発グループが他の開発グループの変更を見たくないというのも、それは、互いに両立し得ない方針の1つです。つまり、各開発グループに個々のブランチが必要となります。

できるだけ後でブランチする。
ブランチ間において、変更の伝達を最小限にするために、ブランチの作成をできるだけ後に延ばします。例えば、リリースされる新機能がメインラインのブランチに含まれている場合、メインラインにおいてできる限りのテストとバグ修正を行ってから、リリース用ブランチを作成します。リリース用ブランチを作成する前にメインラインでバグを修正すれば、ブランチ間で伝達されるべき変更の数は減ることになります。

凍結せずにブランチする。
一方、テストのためにコードラインを凍結しておく必要がある場合、開発者はテストが完了するまで、作業中の変更を伝達させることができません。このようなときは、開発者が引き続き作業できるよう、できるだけ早くブランチを作成して下さい。

いったんブランチすると、ファイルの変更をブランチからブランチへ伝達させなければならない、やっかいな場面に直面します。これは簡単な作業とは言えませんが、これを管理するために実施できることがいくつかあります。

ブランチしてから最も変更が加わっていないブランチの中で、オリジナルの変更を行う。
大きく内容が変わってしまったファイルから変更をマージするよりも、ブランチした時点（共通の祖先）の内容に近いファイルからマージする方が簡単です。なぜならば、今回のマージには関係のない多大な変更内容が、そのマージによって伝達されてしまうかもしれないからです。開発者の意図に反したこのような変更が行われると、マージプロセスは混乱します。最も安定したブランチ上でオリジナルの変更を行うことによって、マージの複雑さを最小限に抑えることができます。例えば、リリース用のコードラインをメインラインからブランチした場合は、最初にリリース用のコードラインでバグ修正を行い、次にそれをメインラインにマージします。もし、最初にメインラインでバグ修正を行うと、その後に実施するリリース用のコードラインへのマージにおいて、本来ならばマージする必要のない変更までマージしてしまう可能性があります。

できるだけ早くかつ頻繁に変更の伝達を行う。
あるブランチから別のブランチへ変更の伝達が可能ならば（ターゲットとなるブランチの方針に違反しないならば）、できるだけ早く伝達して下さい。変更を伝達するのが遅れたり、または後でまとめて行われたりすると、マージ操作は驚くほど複雑になる場合があります。

マージのための適切な担当者を見つける。
変更箇所の衝突を解決するのに最も適した開発者が変更の伝達を行うと、その負荷を軽減することができます。変更の伝達を行う可能性があるのは、以下の開発者です。

(a) ターゲットファイルの所有者
(b) オリジナルの変更を行った開発者
(c) 上記以外の開発者

(c)よりも、(a)または(b)に該当する開発者の方が適していると考えられます。

ビルドとは、複数のオリジナルのソースファイルから、使用可能なソフトウェアを構築する作業のことです。以下に示すいくつかのキープラクティスにしたがえば、ビルドはより管理し易くなり、問題に陥ることも少なくなります。

「ソース＋ツール＝製品」。
ソースファイルと、そのソースファイルを入力とするツールのみが、ビルドにおいて使用されるべきです。記憶に頼った手順や黄色の付箋は、この式には当てはまりません。同じソースファイルとビルドツールを用いた場合、結果として得られる製品は、常に同じであるべきです。もし、機械的なセットアップ手続きがあるならばスクリプトによって自動化し、手動のセットアップが必要ならばビルド手順書として文書化して下さい。また、OS、コンパイラ、インクルードファイル、リンクライブラリ、make用プログラム、実行ファイルのパスを含む、すべてのツールの仕様を文書化して下さい。

すべてのオリジナルソースをチェックインする。
同じ構成物からの再ビルドが確実に行えない場合、構成物のリストが不完全である可能性があります。よく見過ごされるものとしては、Makefile、セットアップスクリプト、ビルドスクリプト、ビルド手順書、およびツール仕様書が挙げられます。これらすべてが、ビルドに必要なソースです。「ソース＋ツール＝製品」であることを忘れないで下さい。

ビルドされたオブジェクトをオリジナルのソースから分離する。
すなわち、ビルドされたオブジェクトは、オリジナルのソースファイルを含むディレクトリには入れないように、ビルドの成果物を整理して下さい。オリジナルのソースファイルとは、テキストエディタ、アプリケーションジェネレータ、または何らかの対話型ツールを用いて「オリジナルの思考プロセス」を具現化したものを指します。一方、ビルドされたオブジェクトとは、生成されたソースファイルを含む、ビルドプロセスによって生成されたすべてのファイルを指します。ビルドされたオブジェクトは、ソースコードを配置している元々のディレクトリ内に置くのではなく、オブジェクト自身のディレクトリツリー内に置いて下さい。この分離により、SCM管理下のディレクトリ範囲を、ソースのみに限定することができます。これによって、容量が大きくなり易いファイルを1ヶ所に集約でき、ビルド用のディスクスペース管理を簡単にすることができます。

共通のビルドツールを使用する。
開発者、テストエンジニア、およびリリースエンジニアは、全員で同じビルドツールを使用すべきです。テストで発見された問題を開発者が再現できない場合や、リリースした製品がテストしたものと違っていた場合には、多くの時間が無駄になってしまいます。「ソース＋ツール＝製品」であることを忘れないで下さい。

頻繁にビルドを行う。
リグレッションテストを伴う全体のビルド（「健全な」ビルド）を頻繁に行うことには、2つの利点があります。1つは、チェックインによって初めてわかる統合上の問題を明確にできるということです。もう1つは、他の開発者が使うことのできるリンクライブラリ等のビルドオブジェクトを、そのビルドによって生成できるということです。健全なビルドは、あらゆるチェックインの後で実行するのが理想ですが、実際にコードラインが開発中の場合にはそれほど頻繁には実行されないのが現実で、通常は夜間の実行となります。たとえ製品のリリース時期がかなり先であっても、コードラインのあらゆるブランチでは、定期的かつ頻繁で完全なビルドとリグレッションテストが行われるべきです。

ビルドのログとビルドの出力を保存する。
ビルドされるオブジェクトすべてに対して、最後に正しく動作するものを生成した際の正確な操作（例えば、コンパイルフラグやリンクコマンドテキストなど）を検索できるようにしておいて下さい。ソースファイルのバージョン（例えば、ラベル）、ツールやOSのバージョン情報、コンパイラの出力、中間ファイル、ビルドされたオブジェクト、およびテスト結果を含むビルドの出力とビルドのログを、将来の参照のためにアーカイブするようにして下さい。大規模なソフトウェアプロジェクトが進行しているときには、あるグループから他のグループにコンポーネントが引き渡されます。しかし、受け取ったグループでは、新しいコンポーネントを直ちにビルドできる状況ではないかもしれません。新しいコンポーネントをビルドし始める際には、前のグループが遭遇した統合の問題を調べるために、以前のビルドのログにアクセスする必要性が出てきます。

SCMプロセスの設計や実装についてそのすべてを探求するには、1つの完全なドキュメントか、場合によっては数冊のドキュメントが必要になるでしょう。そして、既にそのような多くのドキュメントが書かれています。また皆さんの職場には、実装するプロセスの中に盛り込まれることになっている独自の目的や要件があり、それらが何であるかを我々は知りません。しかしながら、プロセスの概念によっては、いかなるSCMの実装に対しても重要なカギになるということを、我々は経験しています。

変更パッケージ（一連の変更）を追跡する。
コードラインにおけるそれぞれのファイルは変更履歴を持ちますが、その履歴におけるそれぞれの世代は、関連したファイル群の中でのみ意味を持ちます。「foo.cに対するこの特定の変更によって、他のどのファイルが変更されたのか？」という質問に対して答を得るには、変更パッケージを追跡するか、さもなければ論理的な変更によって関連付けられたファイル群を追跡しなければなりません。変更パッケージという一連の変更（個々のファイルに対する変更ではありません）は、ソフトウェア開発を目に見える形で表現したものです。SCMシステムには、変更パッケージを追跡するものもあります。もし仮に、現在使用中のSCMシステムがそのような追跡をしないのならば、追跡するプログラムを作成して下さい。

変更パッケージの伝達を追跡する。
変更パッケージを追跡することによる1つの明らかな利点は、ブランチ間での論理的な変更（例えばバグ修正）の伝達が、非常に容易になるということです。しかしながら、ブランチ間で単に変更パッケージを伝達するだけでは十分ではありません。どの変更パッケージが伝達されたのか、どの伝達が保留になっているのか、伝達する側と伝達される側がそれぞれどちらのブランチなのか、という点を追跡しなければなりません。さもなければ、「バグXの修正は、リリースYのコードラインの中に含まれているのか？」という質問に対しても、決して答えることはできないでしょう。繰り返しになりますが、変更パッケージの伝達を追跡するSCMシステム対して、そうでないSCMシステムでは、伝達を追跡するための独自プログラムを作らなければなりません。最終的に、変更パッケージが2つのコードライン間で伝達されたのかどうかを明らかにするための手段として、ファイル同士の"diff（差分表示）"に頼る必要は決してありません。

変更要求と変更パッケージを区別する。
「何をすべきか」と「何を行ったのか」は、異なる情報です。例えば、バグ報告書は「何をすべきか」という情報であり、バグ修正は「何を行ったのか」という情報です。実際、変更要求と変更パッケージには1対多の関係があり得ますので、SCMプロセスにおいてはこれら2つを区別すべきです。

すべてのものに所有者を設定する。
SCMシステムにおけるすべてのプロセス、方針、ドキュメント、製品、コンポーネント、コードライン、ブランチ、そしてタスクには、所有者を設定すべきです。そうすることによって、これらは活用され、成熟されます。所有者が存在しないものというのは、たとえて言うと蟻の道に置かれた障害物のようなものです。― 蟻は、あたかもそれが存在しないかのごとく、単に避けて通っていくだけです。

有効なドキュメントを使用する。
実装する方針と手順は、有効なドキュメントの中に表現されていなければなりません。すなわち、プロセスドキュメント（手順書）は、管理されているコードラインと同様、容易に利用可能でなければなりませんし、更新が行われなければなりません。アクセスできないドキュメントは、役に立ちません。更新できないドキュメントも、ほとんど同様です。プロセスドキュメントは、すべての開発環境からアクセス可能でなければなりません。すべての開発環境というのは、すべての開発者のワークステーションであり、自宅のマシンも含むかもしれません。さらに、プロセスドキュメントは、簡単に更新することができ、その更新が直ちに利用可能にならなければなりません。

ソフトウェア構成管理（SCM）におけるベストプラクティスは、あらゆる分野におけるベストプラクティスと同様に、一度使用してみれば、必ずその効用が明らかになるようなものです。ここで検討したような実践方法は、実際、我々にとって有効でした。しかし、1つの短いドキュメントだけでは、すべてのベストプラクティスを言い尽せないということも、我々は認識しています。それゆえ、場合によっては実践が困難なものも含め、最大の効果を発揮する実践方法を説明しました。

このドキュメントが改善されることを歓迎します。と同時に、前述の実践方法および新たな実践方法にチャレンジされることを、切に望みます。

• 暫定的なコード変更をチェックインしても構いません。
• 関連するコンポーネントがビルド可能でなければなりません。

• チェックイン前に、ビルドしてリグレッションテストに合格しなければなりません。
• チェックインを、バグ修正に限定します。
• 新機能追加はチェックイン不可とします。
• チェックイン後、すべてのQAサイクルが完了するまでブランチは凍結されます。

• すべてのコンポーネントがコンパイルおよびリンクできなければなりません。
• リグレッションテストに合格しなければなりません。
• 開発が完了し、テスト済の新機能についてはチェックインしても構いません