バージョン管理術 - torutkのブログ

開発規模が大きく複数の会社が関わるソフトウェアのバージョン管理をしていると、一筋縄ではいかない問題が多発します。そんなときに、ヒントになりそうな情報をいくつか見かけたのでメモ。

「複数のアジャイルチームでのバージョン管理」

http://www.infoq.com/jp/articles/agile-version-control
InfoQ翻訳記事です。一つのソースコード管理リポジトリに、複数チーム（複数会社）がリリースするような開発体制における効果的なバージョン管理術についてのヒントがあります。

この記事から参照されている文献も読む価値があります。

ベストプラクティス

上述記事から参照されている文献です。

ソフトウェア構成管理製品（Preforce）の開発会社が公開している、構成管理の実践記事

http://www.perforce.com/perforce/papers/bestpractices.html

上記の日本語翻訳が、Perforce日本サポート会社東洋テクニカから公開されています。

「ソフトウェア構成管理の高度な実践方法」

http://www.toyo.co.jp/ss/perforce/technical_bestpractice.html

製品固有の話しはまったくないので、ブランチ機能を持った構成管理ツール全般に役立つ記事となっています。

コードライン方針のプレゼン資料

同じく上述記事から参照されている資料です。
http://www.perforce.com/perforce/conferences/us/2005/presentations/Wingerd.pdf

書籍の一部がオンラインで閲覧可能

同じく上述記事から参照されている文献です。オライリーの書籍（洋書）ですが、参照している章はWeb上でPDFで閲覧可能となっています。
http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

trunkとbranchの考え方：分散開発

いままでは、バージョン管理を導入するときは、誰でも自由にコミットしてよいtrunkと、試験、リリースなどの安定版を作るタイミングで作成したbranchの２つの「コードライン」だけ想定していました。このモデルで、同一開発場所で作業する10人程度の開発チームのときは、とてもうまく回っていました。

現在関わっているプロジェクトでは、複数の会社がそれぞれの作業場所で開発を行い、会社によっては組み合わせる段階で持ち寄ってくる開発体制となっています。ソースコードの管理は今までどおり、開発中のコードは随時trunkにコミットし、試験・リリース作業を行うときにはbranchを作って作業を行う2段階で考えていました。しかし、以前のように「とてもうまくまわっている」とは言えない状況になりました。

例えば、trunkは必ずしもコンパイルが通らない状況となり、branchは目的を果たして閉じたときに、branch上の修正文がtrunkにマージされていないことがしばしば発生する状況です。

取り決めたインタフェースを変更するとき（要するにシグニチャを変更）、インタフェース提供側と利用側が、同じタイミングで作業できなくなったため、一時的に不整合な期間が発生します。同一開発場所で皆が作業しているときは、この状態は分オーダーで解消できましたが、開発場所が分散している今回は日オーダーでの解消となり、その間、ビルドがエラーとなります。

Subversionを導入した場合、大抵はtrunkにどんどんコミットし、試験やリリースを行う際にbranchを作る方法を取ると思います。しかし、開発人数が増えて、作業場所も分散すると、trunkがビルドできない状態が増え、安定しなくなってきます。branchは安定するのですが、修正をbranchに入れて、あとでtrunkに入れる際、修正数が多くなるとマージがうまくいかないケースが増えて、手直しが頻発します。

ここで、前述の記事で提唱している「メインライン」の考え方を入れると、まずtrunkは「メインライン」として、結合テスト完了版をコミットする場所となります。ポリシーとして従来より制約が強くなります。このままでは、各作業者は自分のPCに結合テストを通していないコードを多く抱えることになるため、ポリシーの緩い開発ブランチを作成します。開発ブランチへは、従来のtrunkと同様のポリシー（コンパイルが通る、またはユニットテストが通る）と同じとします。そして、一つの機能（責務）が完了した時点で開発ブランチからtrunkへリリース（Subversion的にはマージ）するというものです。trunkから開発ブランチには、変更点を頻繁に（朝一番にでも）取り込んでおくのがよいでしょう。

開発ブランチは、会社単位あるいは、開発場所が同じであるグループ単位で用意するのがよさそうです。

上書きコミット問題

開発場所が離れているので、それぞれの開発場所で独自にバージョン管理機構が用意されているようです。このバージョン管理同士は連携していないので、各グループの成果を集める場所にファイル一式を運んできて、その時点で作業コピーをチェックアウト（または単にアップデート）して、そこに運んできたファイル一式を上書きし、続いてコミットする、という「上書きコミット」が発生します。そのファイルにもし第三者による修正が入っていたら、修正自体が消えてしまいます。これを防ぐには、運んできたファイルを置いた後、リポジトリとの差分を見て、意図しない削除や修正があれば、そのままコミットせず、確認して手作業で対処を行う必要があります。これは、同一箇所で開発していない限り不可能なので（ソースファイルの運び人は、すべてのソースの変更を知っているわけではなく、単なるお使い番であったりするので）、何らかのバージョン管理機構による救済が必要ではないかと思っています。

　　　　　　　　　　修正B　
　　　　　　　T0  　　↓　　    T1
trunk ーーーー○ーーー△ーーーー○ーーーーー
              ｜ 　　　　　　　 ↑
              ↓ 持ち帰り　　　 ｜持ち込み
開発場所A　 　○ーーーーー△ーー○
　　　　　　　　　　　　　↑
　　　　　　　　　　　　修正A

・A社がT0時点のソースを開発場所Aに持ち帰り、修正Aを施した
・B社がT0時点とT1時点の間に、A社の持ち帰りソースに修正Bを施し、
　コミットした
・A社がT1時点にソースを持ち込み、そのときtrunkの作業コピーを
　updateしてから上書きしてtrunkにコミットした
・修正Bは失われた