製品情報

集中型バージョン管理システムとは

バージョン管理システムは、何をお使いですか?
集中型ですか?または分散型でしょうか?もしかしたらロックベースでしょうか?
GitLabやGitHubのような分散型が最新手法だ、移行しよう、というような流れもありますが、集中型が向いているケースもあります。

今回は、バージョン管理の「集中型」のメリット/デメリットについて整理したいと思います。
以下はGitLab社のブログを引用しております。一部、注釈、および最新ではないリンクを省略しています。原文を確認される場合はこちらから。

集中型バージョン管理システムは、ソフトウェア開発チームに中央サーバーを使用して共同作業を行う方法を提供します。

集中型バージョン管理システム(CVS)

集中型バージョン管理システム(CVCS)は、集中型ソース管理またはリビジョン管理システムとも呼ばれ、サーバーがすべてのコードバージョンを保存するメインの集中リポジトリとして機能します。集中型ソース管理では、すべてのユーザーがメインブランチに直接コミットするため、このタイプのバージョン管理は小規模なチームに適しています。チームメンバーは迅速にコミュニケーションできるため、複数の開発者が同じコードに同時に作業する必要がないからです。集中型ワークフローを成功させるには、強力なコミュニケーションとコラボレーションが不可欠です。

CVS、Perforce、SVNなどの集中型バージョン管理システムでは、ユーザーはサーバーから最新バージョンをプルし、自分のマシンにローカルコピーをダウンロードする必要があります。その後、貢献者はコミットをサーバーにプッシュし、メインリポジトリのマージ競合を解決します。

クライアントサーバーモデルである集中型ワークフローでは、ファイルのロックが可能で、現在チェックアウトされているコードの一部は他のユーザーがアクセスできないため、一度に1人の開発者だけがコードに貢献できます。チームメンバーはブランチを使用して中央リポジトリに貢献し、マージ後にサーバーがファイルのロックを解除します。

集中型バージョン管理システムの例

最も一般的な集中型バージョン管理システムは、Concurrent Versions System(CVS)、Perforce、Subversion(SVN)です。また、Microsoft Team Foundation Server(TFS)(現在はAzure DevOps Serverとして知られています)もあります。

注目すべきは、最も一般的なバージョン管理システムである Git は、集中型 VCS ではなく、分散型 VCS であるということです。

集中型バージョン管理システムの利点は何ですか?

バイナリファイルでも問題なく動作します 

グラフィックアセットやテキストファイルなどのバイナリファイルは大量のスペースを必要とするため、ソフトウェア開発者はこれらのデータを保存するために集中型バージョン管理システムを活用します。集中型サーバーを利用すれば、チームはローカルマシンに履歴全体を保存することなく、数行のコードだけをプルできます。分散型システムのユーザーはプロジェクト全体をダウンロードする必要があり、時間とスペースを消費し、差分を確認することもできません。チームがバイナリファイルを頻繁に扱う場合、集中型システムはコード開発において最も効率的なアプローチとなります。

完全な可視性を提供 

一元化された場所があれば、チームメンバー全員が現在作業中のコードと変更内容を完全に把握できます。この情報により、ソフトウェア開発チームはプロジェクトの状況を把握し、開発者が中央サーバーで作業を共有することでコラボレーションの基盤を築くことができます。集中型バージョン管理システムでは、ユーザーが監視する必要があるデータリポジトリは、ローカルコピーと中央サーバーの2つだけです。

学習曲線を短縮 

集中型バージョン管理は理解しやすく使いやすいため、あらゆるスキルレベルの開発者が変更をプッシュし、コードベースへの貢献をすぐに開始できます。システムとワークフローの設定も簡単で、ソフトウェア開発チームがツールの使用方法を確立するのに多大な時間をかける必要はありません。開発者がワークフローを迅速かつ容易に操作できれば、バージョン管理された変更をマージするための一連の複雑な手順を記憶する必要はなく、機能開発に集中できます。学習曲線が短縮されることで、新しい開発者ができるだけ早く成果を上げることにもつながります。

集中型バージョン管理システムの欠点は何ですか?

単一障害点によりデータが危険にさらされる 

最大のデメリットは、集中型サーバーに組み込まれた単一障害点です 。リモートサーバーがダウンすると、誰もコードで作業したり変更をプッシュしたりできなくなります。オフライン アクセスがないため、中断があるとコード開発に重大な影響が生じ、コードが失われる可能性もあります。停止中は、プロジェクト全体とチーム全体が停止します。ハード ディスクが破損した場合、ソフトウェア開発チームはプロジェクトの実行履歴を取得するためにバックアップに頼る必要があります。バックアップが適切に保存されていない場合、チームはすべてを失ってしまいます。すべてのバージョンを中央サーバーに保存すると、チームはいつでもソース コードを失うリスクがあります。取得できるのはローカル マシンのスナップショットだけですが、プロジェクトの全履歴と比較すると、それはわずかなコード量です。

集中型 VCS とは異なり、分散型バージョン管理システムでは、すべてのユーザーが自分のマシン上に実行履歴のローカル コピーを持つことができるため、障害が発生した場合でも、すべてのローカル コピーが バックアップ コピーとなり 、チーム メンバーはオフラインで開発を継続できます。

遅い速度は開発を遅らせる 

集中型バージョン管理システムのユーザーは、コマンドごとにリモート サーバーと通信する必要があり、コード開発が遅くなるため、迅速に分岐することが難しいことがよくあります。

開発者が変更を中央リポジトリにプッシュする速度が遅く、他の開発者が確認できないため、ブランチ作成に時間がかかり、マージの競合が発生しやすくなります。チームメンバーのネットワーク接続が遅い場合、リモートサーバーへの接続時にコード開発プロセスがさらに煩雑になります。

ソフトウェア開発チームの作業スピードは、機能のリリース速度とビジネス価値の提供速度に直接影響します。チームの開発スピードが遅いと、イテレーションとイノベーションが停滞し、開発者はアプリケーションへの変更反映に時間がかかることに不満を抱く可能性があります。リモートサーバーやネットワークがダウンすると、リリースが遅れる可能性があり、チームメンバーは失われた時間を補うことができず、変更を迅速にプッシュできなくなります。

変化を促すための安定した瞬間はほとんどない 

集中型のワークフローは小規模なチームでは活用しやすいですが、大規模なチームで共同作業を行う場合には限界があります。複数の開発者が同じコードに取り組む場合、変更をプッシュする安定したタイミングを見つけるのが難しくなります。不安定な変更はメインの中央リポジトリにプッシュできないため、開発者はリリース準備ができるまでローカルで保管しておく必要があります。

ユーザーが変更のプッシュを遅らせると、ソフトウェア開発プロジェクトの遅延やマージ競合が発生する可能性があります。これは、チームの他のメンバーがユーザーのマシンにのみ存在する変更を把握できないためです。安定性と速度の問題に対処した後、変更が中央リポジトリにプッシュされた後、ユーザーはマージ時に競合を迅速に解決し、チームの他のメンバーがコードに貢献できるようにする必要があります。この安定性の欠如が、多くのチームが Gitなどの別のバージョン管理システムに移行する原因となっています。

結論

ソフトウェア開発というダイナミックな領域において、集中型バージョン管理システム(CVCS)は、効率的なコラボレーションと合理化されたプロセスを目指すチームにとっての基盤として浮上しています。このシステムは、中央サーバーのパワーを活用して包括的なバージョン履歴を維持します。個々の開発者がメインブランチに直接貢献できるようにすることで、CVCSは開発プロセスを簡素化します。

CVCS の本質は、バージョン管理のための統合プラットフォームを提供し、すべてのチーム メンバーが最新のコードで作業できるようにすることで、生産性を向上させ、透明性の文化を育むことにあります。


弊社パートナー様はNetworld Dev Portal アカウント(無料)登録いただくと、GitLabパートナー制度や DevSecOps関連提案資料などのパートナー限定コンテンツがご覧いただけます。

DevSecOps全般、GitLab製品または本サイトについては以下よりお問い合わせ下さい。

関連記事