分散バージョン管理システムとエンタープライズ-良い組み合わせですか？
分散ソース管理システム（DVCS-Mercurialなど）がオープンソースプロジェクトに適している理由がわかります。
しかし、それらは企業にとって意味がありますか？ （TFSなどの一元化されたソース管理システムを介して）
DVCSのどの機能が、多くの開発者を抱える企業に適しているか、または劣っていますか？ （集中型システム経由）
大規模な銀行会社にDVCS（この場合はGit）を導入しました。ここでは、Perforce、SVN、またはClearCaseが集中型のVCSとして選択されました。
私はすでに課題を知っていました（以前の回答を参照してください " 最終的に企業ソフトウェアのDVCSに移行できますか？SVNはまだ開発のために「必須」ですか？ "）
私は3つの面で挑戦されてきました：
集中化：分散型モデルにはメリットがあります（そして、にアクセスしながら、プライベートコミットまたはネットワークなしでの作業を可能にします完全な履歴）、すべての開発者のメインリファレンスとして機能する集中型リポジトリの明確なセットが必要です。
authentication：DVCSを使用すると、コードを「サインオフ」（コミット）することができます...ほとんどの人（作成者 "
foo"、メール"[email protected]"）。git config user.name fooまたはgit config user.name whateverNameIFeelToHaveを実行して、偽の名前を含むすべてのコミットを含めることができます。
これは、大企業で使用される独自の集中型の「ActiveDirectory」ユーザー参照とうまく混ざりません。authorization：デフォルトでは、anyリポジトリのクローンを作成したり、プッシュしたり、プルしたりして、anyブランチ、または任意のディレクトリ。
機密性の高いプロジェクトの場合、これはブロッキングの問題になる可能性があります（銀行業界は通常、非常に限られた数の人々に厳密な読み取り/書き込みアクセスを必要とする一部の価格設定または量子アルゴリズムを非常に保護しています）
答えは（Gitセットアップの場合）次のとおりです。
- 集中化：すべてのユーザーがアクセスできる必要があるリポジトリ用に一意のサーバーが設定されています。
バックアップが処理されています（毎日増分、毎週いっぱい）。
DRP（Disaster Recovery Plan）が実装され、別のサイトに2番目のサーバーがあり、 [〜＃〜] srdf [〜＃〜] を介してリアルタイムのデータ複製が行われます。
このセットアップ自体は、必要な参照またはツールのタイプ（DVCS、Nexusリポジトリ、メインのHudsonスケジューラーなど）とは無関係です。本番環境へのリリースに不可欠なツールです。バックアップとDRを備えたサーバーにインストールされます。
。
- authentication：ユーザーがメインリポジトリにアクセスできるのは2つのプロトコルのみです：
- sshベース、公開鍵/秘密鍵：
- 組織外のユーザー（オフショア開発など）に役立ちます。
- active Directoryマネージャーが作成したくない汎用アカウントに役立ちます（「匿名」アカウントになるため）：実際の人がその汎用アカウントを担当する必要があります、そしてそれは秘密鍵を所有しているものになります
- httpsベース、LDAP設定を介してユーザーを認証するApacheを使用：このように、これらのリポジトリでのgit操作には実際のログインを提供する必要があります。
Gitは スマートhttpプロトコル を提供し、httpを介してpull（読み取り）だけでなく、httpを介してPush（書き込み）も許可します。
- sshベース、公開鍵/秘密鍵：
認証部分は、post-receiveフックによってGitレベルでも強化され、atリポジトリにプッシュしているコミットの少なくとも1つには、shhまたはhttpプロトコルで検出されたユーザー名と同じ「コミッター名」があります。
つまり、git config user.nameを正しく設定する必要があります。そうしないと、中央リポジトリに対して実行するプッシュが拒否されます。
。
- authorization：以前の両方の設定（sshまたはhttps）は、という名前の同じPerlスクリプトのセットを呼び出すように配線されています- gitolite、パラメーターとして：
- これら2つのプロトコルによって検出された実際のユーザー名
- ユーザーが実行したいgitコマンド（クローン、プッシュ、またはプル）
gitolite Perlスクリプトは単純なテキストファイルを解析します 承認（すべてのリポジトリ、特定のリポジトリ内のブランチ、またはリポジトリ内のディレクトリに対する読み取り/書き込みアクセス）が設定されている場所。
gitコマンドに必要なアクセスレベルがそのファイルで定義されているACLと一致しない場合、コマンドは拒否されます。
上記は、Git設定に実装する必要があるものを説明していますが、さらに重要なことは、独自のユーザーベースを持つ大企業でDVCS設定を理解するために対処する必要がある主な問題を示しています。
次に、そしてそのときだけ、DVCS（Git、Mercurial、...）は次の理由で値を追加できます。
複数のサイト間のデータ交換：これらのユーザーはすべて同じActive Directoryを介して認証されますが、世界中（私が働いていた会社）に配置できます。通常、2つまたは3つの国のチーム間で開発が行われています）。 DVCSは、これらの分散したチーム間で効率的にデータを交換するために自然に作成されます。
環境間でのレプリケーション：認証/承認を処理する設定により、他の専用サーバー（統合テスト、UATテスト、実稼働前）にこれらのリポジトリを複製できます。および展開前の目的）
プロセスの自動化：リポジトリのクローンを作成する簡単さは、「保護されたコミット」を使用した単体テストの目的で、1人のユーザーのワークステーションでローカルに使用することもできます。 "テクニックと他の巧妙な使用法：" これまでに見たソースリポジトリの最も巧妙な使用法は何ですか？ "を参照してください。
要するに、あなたは以下を担当する2番目のローカルリポジトリにプッシュすることができます：- さまざまなタスク（ユニットテストまたはコードの静的分析）
- これらのタスクが成功した場合、メインリポジトリにプッシュバックします
- whileこれらのタスクの結果を待たずに、最初のリポジトリで作業を続けています。
。
エンタープライズ環境でGitが直面する最大の問題は、パスベースの読み取りアクセス制御の欠如です。リポジトリへの読み取りアクセスを取得した場合、すべてを取得することは、Gitのアーキテクチャ（およびほとんどのDVCSを想定しています）に固有のものです。ただし、プロジェクトでスパースチェックアウトが必要になる場合があります（つまり、ソースに近い機密データをバージョン管理したい場合、またはプロジェクトの一部の選択的なビューをサードパーティに提供したい場合）。
箱から出して、Gitは権限を提供しません-あなたはあなた自身を書くためのフックを持っています。
人気のあるリポジトリマネージャーのほとんどGithubEnterprise、Gitlab、Bitbucketは、ブランチベースの書き込み制限を提供します。 Gitoliteを使用すると、パス（およびその他）ベースの書き込み制限を提供して、よりきめ細かくすることができます。
読み取りアクセスのサポートについて聞いた唯一のリポジトリマネージャーは、PERFORCEバックエンド上にgitプロトコルを再実装するPerforce Helixですが、実際の経験はありません。有望ですが、「プレーン」なgitとの互換性が気になります。
他のコメントに追加するために、Corporate Central Repositoryを持つことができない理由はないことに気付くでしょう。技術的には別のリポジトリですが、本番環境を出荷するリポジトリです。私は30年以上VCSの何らかの形を使用してきましたが、Mercurialへの切り替えは、初めてきれいな田舎の空気を吸う都会の少年のようだったと言えます。
DSCSは、オフラインまたは低速ネットワーク用の集中型システムよりも（一般的に）優れたストーリーを持っています。それらはより高速になる傾向があり、これは多くのチェックインを行う開発者（TDDを使用）にとって非常に注目に値します。
一元化されたシステムは、最初は理解しやすく、経験の浅い開発者にとってはより良い選択かもしれません。 DVCSを使用すると、グリーンスタイルのコーディングでレッドグリーリファクタリングチェックインを実行しながら、多数のミニブランチを作成して新しい機能を分離できます。繰り返しますが、これは非常に強力ですが、かなり精通した開発チームにとってのみ魅力的です。
排他的ロックをサポートするための単一の中央リポジトリを持つことは、デジタル資産や非テキストドキュメント（PDFやWordなど）のようにマージできないファイルを扱う場合に意味があります。これにより、混乱して手動でマージすることができなくなります。
開発者の数やコードベースのサイズがそれほど影響しているとは思いません。どちらのシステムも、大きなソースツリーと多数のコミッターをサポートしていることが示されています。ただし、大規模なコードベースやプロジェクトの場合、DVCSは分散型リモートブランチをすばやく作成する際に多くの柔軟性を提供します。これは一元化されたシステムで行うことができますが、良い面と悪い面の両方について、より慎重に検討する必要があります。
要するに、考慮すべきいくつかの技術的側面がありますが、チームの成熟度とSCCSに関する現在のプロセスについても考慮する必要があります。
少なくともtfs2013では、ローカルワークスペースとは切り離して作業することができます。分散型と集中型はビジネスによって定義され、開発中のプロジェクトのニーズと要件によって異なります。
エンタープライズプロジェクトの場合、ワークフローとドキュメントをコード変更に接続する機能は、ビジネス要件と高次の要素を特定の変更、バグ、または機能の追加に対処する特定のコード変更に接続する上で重要になる可能性があります。
ワークフローとコードリポジトリ間のこの接続により、TFSはコードリポジトリのみのソリューションから分離されます。より高次のプロジェクト監査が必要な場所では、TFSのような製品だけがプロジェクト監査要件の多くを満たします。
アプリケーションライフサイクル管理プロセスの概要については、こちらをご覧ください。
http://msdn.Microsoft.com/en-us/library/vstudio/fda2bad5（v = vs.110）.aspx
私たちのチームは、Mercurialに切り替える前に約3年間TFSを使用していました。 HGのブランチ/マージサポートはTFSよりもはるかに優れています。これは、DVCSが痛みのないマージに依存しているためです。
私にとって彼らが提供する最大のものはスピードです。最も一般的な操作では、集中型のソース管理よりも桁違いに高速です。
切断された状態で作業することも大きなプラスです。
分散ソースモデルは企業では絶対に理にかなっていますが、チームの構造によって異なります。
分散ソース管理により、独自のワークフローを柔軟に作成できます。
可能であれば、大きなチームを想像してみてください。その中には、別々の機能ブランチで作業している小さなチームがあります。
- これらのチームはすべて、独自のビルド自動化/チェックイン制御メカニズムを備えた独自の中央リポジトリを持つことができます。
- 彼らはどこでも仕事をすることができ、彼らが望むときはいつでも彼らの地元の仕事をバックアップすることができます。
- 次に、グループ間で共有するチェックインを選択できます。
- 彼らは、単一の個別のインテグレーターを持ち、自分のマシンで作業し、マージを実行し、なし他の人に影響を与えることができます。
これらは、従来の集中型サーバーでできたことができることですが、@ Brookが指摘しているように、集中型モデルは拡張する必要がありますが、分散型モデルは- すでにシャーディングされているため、サーバーを垂直方向にスケーリングする必要はありません（または少なくともそれ以下）。