集中型バージョン管理システムとは？
集中型バージョン管理システムを使用すると、ソフトウェア開発チームは中央サーバーを使用して共同作業ができます。
集中型バージョン管理システム （CVCS）は集中型ソース管理またはリビジョン管理システムとも呼ばれ、サーバーはすべてのバージョンのコードを格納する主要な集中型リポジトリとして機能します。集中型ソース管理を使用してすべてのユーザーがメインブランチに直接コミットするため、このタイプのバージョン管理は、多くの場合、チームメンバー同士が迅速にコミュニケーションを取れ、2人の開発者が同時に同じコードに取り組まないようにできる小規模なチームに適しています。集中型ワークフローを成功させるには、十分なコミュニケーションとコラボレーションが
重要です。
CVS、Perforce、SVNなどの集中型バージョン管理システムでは、ユーザーはサーバーから最新バージョンを取得し、自分のマシンにローカルコピーをダウンロードする必要があります。次に、コントリビューターはコミットをサーバーにプッシュしてメインリポジトリ上のマージの競合を解決します。
クライアントサーバーモデルとして集中型ワークフローを使用すると、現在チェックアウトされているコードの一部を他ユーザーがアクセスしないようにファイルをロックでき、一度にコードにコントリビュートできるのは1人の開発者のみとなります。チームメンバーはブランチを使用して中央リポジトリにコントリビュートし、サーバーはマージ後にファイルのロックを解除します。
バイナリファイルに最適
グラフィックアセットやテキストファイルのようなバイナリファイルは大きな容量を必要とするため、ソフトウェア開発者はこうしたデータの保存に集中型バージョン管理システムを利用しています。集中型サーバーを使用すると、チームはローカルマシンに履歴全体を保存することなく数行のコードを取得できます。分散型システムのユーザーはプロジェクト全体をダウンロードする必要があるため、時間とスペースが浪費され、差分を実行できなくなります。チームが定期的にバイナリファイルを扱う場合、集中型システムはコード開発に最も効率的なアプローチとなります。
完全な可視性
一元化されているため、現在どのようなコードに取り組んでいるのか、どのような変更が行われているのかなどの情報をすべてのチームメンバーが完全に把握できます。この知識は、ソフトウェア開発チームがプロジェクトの状態を理解するのに役立つばかりでなく、中央サーバーで開発者が作業を共有する必要がある状況においてコラボレーションの基盤となります。集中型バージョン管理システムには、ユーザーがモニタリングする必要のある2つのデータリポジトリ、ローカルコピーと中央サーバーのみが存在します。
学習時間の短縮
集中型バージョン管理システムは簡単に理解して使用できるため、開発者の技能水準を問わず、誰でも変更をプッシュしてコードベースに素早く貢献することができます。システムとワークフローのセットアップも簡単で、ソフトウェア開発チームのツールの使用方法を特定するのに多大な時間を費やす必要はありません。開発者がワークフローを迅速かつ簡単にナビゲートできるようになると、バージョン管理された変更をマージするための一連の複雑な手順を記憶する必要なく、機能開発に集中できるようになります。学習時間が短縮されるため、新しく加わった開発者もすぐに貢献できるようになります。
障害発生時のデータリスク
最大の欠点は、集中型サーバーを使用することによる、避けられない障害発生時のリスクです。リモートサーバーがダウンした場合、誰もコードを処理したり、変更をプッシュしたりすることができなくなります。オフラインでアクセスできないということは、何らかの混乱がコード開発に大きな影響を与え、コードが失われる可能性さえあるということです。停止中は、プロジェクトとチーム全体が止まってしまいます。ハードディスクが破損した場合、ソフトウェア開発チームはプロジェクトの実行履歴を取り出すためにバックアップに頼らざるを得ません。バックアップが適切に保存されていなければ、チームはすべてを失うことになります。すべてのバージョンを中央サーバーに保存すると、チームは常にソースコードを失うリスクにさらされます。ローカルマシン上のスナップショットのみが復元可能ですが、それはプロジェクトの全履歴に比べて、少量のコードにすぎません。
集中型VCSとは異なり、分散型バージョン管理システムでは、すべてのユーザーが実行履歴のローカルコピーを自分のマシンに保存できるため、障害が発生した場合でも、すべてのローカルコピーがバックアップコピーとなり、チームメンバーはオフラインで開発を続けることができます。
スピードの遅さによる開発の遅れ
集中型バージョン管理システムのユーザーは、コマンドを実行するたびにリモートサーバーに通信する必要があるため、迅速にブランチを行うことが難しく、コード開発が遅れることがよくあります。
ブランチは時間のかかる作業となり、開発者が自分の変更を中央リポジトリにプッシュしても、他のメンバーが確認できないため、マージの競合が発生しやすくなります。チームメンバーのネットワーク接続が遅い場合、リモートサーバーに接続しようとすると、コード開発プロセスがさらに時間がかかるものとなります。
ソフトウェア開発チームの作業スピードは、機能のリリーススピードやビジネス価値の提供にダイレクトに影響します。チームの開発スピードが遅いと、イタレーションやイノベーションが停滞し、開発者はアプリケーションに変更が反映されるまでに時間がかかることに不満を感じるようになります。リモートサーバーやネットワークがダウンしている場合、リリースに間に合わなくなる可能性があり、チームメンバーは時間の遅れを取り戻すことができず、変更を迅速にプッシュすることができなくなります。
変更をプッシュする安定したタイミングがあまりない
集中型のワークフローは、小規模なチームにとっては活用しやすいのですが、大規模なチームがコラボレーションする場合は限界があります。複数の開発者が同じコードに取り組む場合、変更をプッシュする安定したタイミングを見つけるのが難しくなります。不安定な変更はメインの中央リポジトリにプッシュできないため、開発者はリリースの準備が整うまでローカルにとどめておかなければなりません。
ユーザーが変更をプッシュするのが遅れるため、ソフトウェア開発プロジェクトは遅延し、他のメンバーがユーザーのマシンにのみ存在する変更を把握できないため、マージ競合が発生する可能性があります。安定性とスピードの問題に対処した後、ようやく変更が中央リポジトリにプッシュされ、ユーザーは、チームの他のメンバーがコードにコントリビュートできるようにマージ時に競合を迅速に解決しなければならなくなります。安定性の欠如が理由で、多くのチームがGitのような別のバージョン管理システムに移行しているのです。
GitLabが推進するソフトウェア開発の進化について見る
