14

私はTFS 2010を使用しています。現在は、Gated Check-inビルドをトランク(MAIN)ブランチのみで使用しています。そして、DEVとRELEASEブランチでCIを使用します。ゲーテッド・チェックインの使用時期

  • なぜすべてのブランチでGated Check-inビルドを使用しないのですか?
  • どのシナリオでは、DEVおよびRELEASEブランチでGated Check-inビルドを使用しないでください。
  • すべてのブランチで常にゲーテッドチェックインビルドを使用する方が良いですか?
+0

トリガされたビルドと継続的なインテグレーションの違いについて、あなた自身の言葉で説明できますか? – kroonwijk

+0

Kroonwijk;私は私の質問を修正した。それは、トリガーされていない、Gated Check-inと言えます。 –

+0

ありがとう!今は明らかです。 – kroonwijk

答えて

9

は、我々はまた、DEV /機能ブランチ(それらの多く)で、メインブランチとCIにゲーティングありません。

ゲーテッドは、ブランチのためのより多くの保護を提供していますが、全体の開発チームは、そのブランチの変更を行っている場合は非常に大規模なチームと大規模なコードベースで、それはキューをバックアップすることができます。

CIはまた、任意の問題を迅速に巻き込まれることを知っている開発者でもう少し信頼と保護を提供します。もう少し楽観的であり、devブランチにふさわしいチームをもっと速く動かすことができます。

devsはユニットテストを実行し、変更しているコードをテストします。 CI(チームに影響を与える)とGated(待ち行列の時間を消費する)はテストに取って代わるべきではありません。

チーム全体は、サイクルの大多数のため、エンドゲームの安定化の間に、より多くの人々との高い枝にCIを用いた特徴の/ devブランチである - これらの後者の条件の両方がゲートさのためにケースをサポートしています。

大規模なチームでは、ビルド時間が簡単ではなく、完全なテストスイートも簡単ではない場合に、CIビルドとローリングテストを並行して実行する必要があります。このシナリオでは、人はチェックインしています。CIはチェックインの最後のバッチを実行してビルドを実行し、ビルドによって別のマシンがドロップされてテストスイートが実行されます。

+0

これも私たちがやっていることです。 –

+0

ゲーテッド・キューがバックアップされている場合、チームがサブミットをマージするとメリットがあるようです。ほとんどの変更が拒否されないと仮定して、一度に2つ以上の変更を検証すると、キューの待機時間が短縮される可能性があります。 –

4

私が知っている理由は実際にはありませんあなたが行ったすべての変更でGated Check-inを実行するのはなぜですか?ただし、ゲーテッド・チェックインの前提条件は(全般的に)必要です。チェックインが受け入れられる前に実行したいテスト(ユニット)を含め、全体のビルド時間は数分を超えてはなりません。それ以外の場合は、チェックインが受け入れられるか、開発者にとって悪い場合には、却下されるまでに多くの時間がかかります。デベロッパーチームにとっては、もう少し複雑で、少なくとも慣れているものもあります。

継続的インテグレーションは、(私の意見ではローリングのビルドの形で最適化された)、それが受け入れられるかないされる場合は不確実性がなくても、開発者のチェックインのコードを持つことができます。重要なのは、デベロッパーは常に、できるだけ早くチェックインの結果が否定的であることに直面しなければならないということです。もしあなたがそれを達成できれば、私はGatedのチェックインよりも好きです。私たちの非常に大規模なチームで

+2

大きなコードベースの非常に大きなチームでは、gatedはより高いレベルのリリースタイプのブランチでのみ保証されます。チームは機能/ devブランチでgatedを買う余裕はありません。チームのサイズとコードベースのために、それはバックアップします。下の私のポストを参照してください。 – bryanmac

3

それはむしろ誰か(必然的に)間違いを犯したときにチーム全体でその痛みを共有するよりも、開発者のチェックインに痛みを制限したので、私はどこにでもゲートで囲われたチェックインのを好みます。

前述のように、ゲーテッド・チェックインをすばやく保つことが重要です。最も重要なチェックを実行するゲーテッド・チェックイン、時には時間のかかるチェックを実行するゲーテッド・チェックインが成功した後に開始するCIビルドがあります。

+1

問題を解決するかどうかはわかりません。私の仕事では完全なビルド+すべてのテストは新しいハードウェアで24時間かかります。私たちは約30分で実行可能なスモークテストを実施していますが、問題は当然ながら、より徹底的にまたは徹底的に多くの時間を要するテスト(データベースのあるバージョンから別のバージョンのデータにうまく移行できるテストなど) 「長い」カテゴリーに押し込まれた。しばしば煙が何も捕らえない場合、CIは「長い」カテゴリを実行し、12のテストは失敗します。それまでにレビュー担当者はしばしばコードを承認しており、いずれにしても残りのチームは傷ついています – Mike

関連する問題