私は TFS 2010 を使用しています。現在、トランク (MAIN) ブランチでのみ Gated Check-in ビルドを使用しています。また、DEV ブランチと RELEASE ブランチでは CI を使用しています。
私たちの非常に大規模なチームでは、メイン ブランチでゲートを行い、開発/機能ブランチ (それらの多く) で CI も行います。
Gated はブランチに対してより多くの保護を提供しますが、非常に大規模なチームと大規模なコード ベースを使用すると、開発チーム全体がそのブランチで変更を行っている場合にキューをバックアップできます。
CI は、開発者をもう少し信頼して保護を提供し、問題がすぐに見つかることも知っています。これはもう少し楽観的で、開発ブランチに適した、チームがより速く動くことを可能にします。
どちらの場合も、開発者は単体テストを実行し、変更中のコードをテストします。CI (チームに影響を与える) と Gated (キューで時間を消費する) はテストに取って代わるべきではありません.
チーム全体は、サイクルの大部分で CI を使用する機能/開発ブランチにいて、エンドゲームの安定化の間はより多くの人々がいるより高いブランチにいます。
大規模なチームでは、ビルド時間が自明ではなく、完全なテスト スイートも自明ではない場合、問題をより迅速に見つけるために、CI ビルドとローリング テストを並行して実行する必要もあります。そのシナリオでは、人々がチェックインし、CI がチェックインの最後のバッチを取得してビルドを実行し、ビルドがドロップされると、別のマシンがテスト スイートを取得して実行します。
変更を加えるたびにゲートチェックインを行わない理由を私が知っている理由は実際にはありません。ただし、（一般的に）ゲートチェックインを実行するための前提条件があります。チェックインが受け入れられる前に実行したい（単体）テストを含め、全体的なビルド時間は数分を超えてはなりません。 。そうしないと、チェックインが受け入れられるまでにかなりの時間がかかり、開発者にとってはさらに悪いことに拒否されるまでに時間がかかります。開発チームにとっては、もう少し複雑であるか、少なくとも慣れるべきものです。
継続的インテグレーション（私の意見では、ローリングビルドの形で最適化されています）を使用すると、開発者は、コードが受け入れられるかどうかを不確実にすることなく、コードをチェックインできます。重要なのは、開発者は常にチェックインの否定的な最終結果にできるだけ早く直面する必要があるということです。あなたがそれを達成することができれば、私はそれがゲートチェックインよりも好きです。
誰かが (必然的に) 間違いを犯したときにチーム全体とその苦痛を共有するのではなく、開発者のチェックインに苦痛を限定するので、私はどこでもゲート チェックインを好みます。
前述のように、ゲート付きチェックインを迅速に行うことが重要です。最も重要なチェックを実行するゲート チェックインを実行し、ゲート チェックインが成功した後に CI ビルドを開始して、より時間のかかるチェックを実行することがあります。