Mercurialではじめる分散構成管理

第5回 分散による「多段連携」 ~ 大規模開発への応用

この記事を読むのに必要な時間:およそ 3 分

企業においてフリーソフト/オープンソースソフトを導入しようとすると,以下のような意見に反対されることがあるのではないでしょうか?

大規模開発では使えないんでしょ?

そこで今回は,大規模開発における構成管理を効率よく運用するための,Mercurialのリポジトリ分散性を活かした,幾つかのアイディアについて説明したいと思います。

中央集約形式の問題

ある程度以上の規模の開発の場合,事前に(あるいは開発を進めながら)取り決めたI/Fを介して連携する複数の部位に全体を分割し,複数のチームがそれぞれの担当分を開発する,という進め方をするのが一般的です。

このような開発体制を採用した場合,単一サーバが全ての要求を受け付ける中央集約形式のCVSやSubversionでは,サーバの応答性能低下が懸念されます。

図1 フラットな構成

図1 フラットな構成

また,全ての開発者が同様にメイントランクにアクセスしていたのでは,他拠点の開発成果とのマージが頻発しますので,拠点ごとにブランチを作成するなどの必要性が出てきます。

しかし,各ブランチ毎のアクセスを制限する方法がありませんから,他拠点成果との混交やメイントランクへのコミットが,誤操作等によって発生する危険が残ります。

この問題はリリースにおける成果混交と同じで,単にメンバー全員の習熟度を一定水準以上に保つだけ(開発体制が大きくなると,保つだけでも思いのほか難しいものですが)では解決しません。

ここで,各拠点ごとのリポジトリと,成果集約用のリポジトリに分離したとします。

図2 情報損失のある多段構成

図2 情報損失のある多段構成

しかし,リポジトリ間で作業成果を行き来させた際には,履歴等の構成管理情報が失われてしまいます。

各拠点での履歴などは必要ない

という場合もあるでしょうが,参照しない(do not)ことと,参照できない(can not)ことは全くの別物です。

著者プロフィール

藤原克則(ふじわらかつのり)

Mercurial三昧の日々が嵩じて, いつの間にやら『入門Mercurial Linux/Windows対応』を上梓。凝り性なのが災いして,年がら年中アップアップな一介の実装屋。最近は仕事の縁が元で,OpenSolarisに入れ込む毎日。

コメント

コメントの記入