TFS (Team Foundation Server) から Git への移行を検討していますが、ゲート チェックイン (事前テスト済みコミットまたは遅延コミットとも呼ばれます) に対する TFS のサポートに一致するものが見つかりません。
Atlassian Bamboo はゲート チェックインをサポートしていません。TeamCity はそれをサポートしていますが (用語を使用した「遅延コミット」)、Git はサポートしていません。Jenkins を単独で、または Jenkins+Gerrit を使用することには大きな欠点があり、TFS のゲート付きチェックイン機能には近づきません。(このビデオで Jenkins の作成者自身が説明している欠点: http://www.youtube.com/watch?v=LvCVw5gnAo0 )
Git は (正当な理由で) 非常に人気がありますが、人々はこの問題をどのように解決していますか? 現在の最善の解決策は何ですか?
gitの使用を開始し、ワークフローを使用して事前テスト済みのコミットを実装しました（これは今日テストを終了しました）。
基本的に、各開発者には、読み取り/書き込みアクセス権を持つ個人リポジトリがあります。この場合のビルドサーバーTeamCityは、これらの個人リポジトリを使用してビルドし、成功した場合は変更を「グリーン」リポジトリにプッシュします。開発者には「green」への書き込みアクセス権がなく、TeamCityビルドエージェントのみが書き込みできますが、開発者は「green」から一般的な更新をプルします。
つまり、開発者は「グリーン」からプルし、パーソナルにプッシュし、TeamCityはパーソナルからビルドし、グリーンにプッシュします。
このブログ投稿は、個人リポジトリ用のGitHubフォークを使用して、使用している基本モデルを示しています（フォークを使用すると、リポジトリの数が手に負えなくなり、コストが高くなることはなく、開発者が個人ビルドを管理できることを意味します、フォークしてからチームシティビルドジョブを作成して、コードを「グリーン」にプッシュできるため）：
各開発者は独自のビルド構成を持っている必要があるため、これはTeamCityで設定するためのより多くの作業です。前のビルドステップが失敗した場合でも（テストのように:)）、TeamCityはすべてのビルドステップ（最後の「pushto green」ステップを含む）を実行するように見えるため、実際には2つの構成である必要があります。開発者のためにビルドし、次にそれに依存する別のビルド構成。ビルドが機能したと仮定してプッシュを実行します。
gitにはさまざまな哲学があります-コミットは簡単です、あなたが望むようにコミットしてください。何か問題がある場合は、後で変更できます。そして、マージは簡単です。したがって、適切なワークフローを編成できます。たとえば、開発者は別のブランチでコミットできます。ブランチがテストされると、メインブランチにマージされる可能性があります。
TFS を中央リポジトリとして使用し、GIT をローカル DVCS ソリューションとして使用してみませんか?
これにより、ローカルでビルドしてコミットし、必要なものを TFS サーバーにプッシュして、ゲート ビルドを実行できます。
時には、両方の長所を併せ持つことも良いことです...