TFSのゲートチェックインの欠点
私は常にTFSの継続的インテグレーション（CI）ビルドを使用してきました。しかし、私の最後のプロジェクトでは、ゲートチェックイントリガーの使用を開始しました。
ゲートチェックインを使用する場合、デメリットはありますか？チームが壊れたコードをチェックインできない場合、CIトリガーの目的は何ですか？
ゲートチェックインは、継続的な統合ビルドの一種です。 TFSでは、検証されるコードを含むshelvesetを作成し、そのコードのビルドを実行します。そのコードが正常にビルドされ、構成されたすべての単体テストに合格した場合のみ、コードは実際にコミットされます。
継続的インテグレーションは異なります-CIでは、ビルドの結果として何が起こるかに関係なくコードがコミットされます。不正なコードがコミットされたためにCIのビルドが失敗した場合、ソース管理では、コードはすべてのユーザーが入手できる状態のままです。
意見に基づく部分について：ゲートチェックインは、さまざまなレベルのスキル/経験のある多数の開発者がいる場合に役立ちます。壊れたコードがソース管理に入らないようにするためです。欠点は、コードがコミットされてから他の人が利用できるようになるまでの時間が長くなり、ビルドが正常に完了するのを待っている人が親指をいじっているという状況につながる可能性があることです。
ゲートチェックインを一時的に使用することをお勧めします。ゲートチェックインビルドが大量に失敗する場合、その仕事をしていて、悪いコードがコミットされるのを防いでいます。時間が経つにつれて、チームが成熟し、ゲートチェックインビルドがめったに失敗しない場合、それはあまり役に立たないため、問題が発生する可能性があるすべてのコミットを遅らせるのではなく、継続的な統合に切り替えて、失敗したビルドを修正する必要があります。
ゲートチェックインを使用すると、コミットが難しくなり、遅くなります。それは一般的にbadのことです。なぜなら：
- TDDでは、メンバーは失敗したテストでコミットをプッシュできる必要があります
- 失敗したテストとしてバグを報告することは非常に便利です
- WIP（作業中）ブランチで協力する場合、メンバーはダーティな変更をプッシュして他の人がすぐに利用できるようにする必要があります
- 大きな変化に取り組むとき、他のメンバーが終了する時間を投資する前に未完成の作業をレビューできるようにすると便利です。
- スナップショット/バックアップの形式として不完全な作業を定期的にコミットすることを好む人が多い
- ブランチを頻繁に切り替える場合に、不完全な作業をコミットするのは素晴らしいことです（特に新しいファイルの場合は、限られたヘルプのみをスタッシングします）。
- QAは時間制限されるべきではありませんが、コミットには時間がかかりません
- とにかくclean環境でコードのQAを行う必要があります。特定のローカル環境は、CIサーバーほど原始的ではない可能性が高いです。
- 同様に、QAは多くの場合、環境のマトリックス（異なるコンパイラーバージョン、異なるブラウザー、異なるOSなど）で実行する必要があります。セットアップのコストは中央CIによりよく投資されます
したがって、gatedチェックがオンになっているシナリオは問題ありません。
- VCSが分岐を困難にしている、または会社が分岐を許可していない
- プロジェクトは小さい
- 1人の開発者のみ
- CIがありません
- 特定の長命ブランチのみがゲートによって保護されます（ただし、CIに代わるものではありません）