コミットごとに構築-継続的デリバリー
継続的デリバリーに関するビデオを視聴したところ、コミットごとにビルドをトリガーしてユニットテストを実行することが提案されました。私たちの10人の開発者チームとビルド時間10分以上の場合、これが1時間でどのように機能するのかと思うと、すべての開発者が何かを提供する可能性があります==>結局、複数のビルドが同時に進行する可能性があります。
よろしいですか？それは良い習慣ですか？
現在、ビルドはオンデマンドで手動でトリガーされます。
すべてではないにしても、ほとんどのCIプラットフォームでは、プロジェクト/ブランチごとに1つのビルドに制限されます。
開発者が別々のブランチで作業している場合、実際には同時に分離されたビルドがある可能性があります。これにより、CIサーバーでバックアップが発生する可能性がありますが、ビルドを実行するスレーブマシンを追加することで解決できます。
彼らが同じブランチで作業している場合、ビルドはコミットごとに次々と発生します。コミットの頻度が高すぎてCIサーバーが追い付かない場合、これは問題になる可能性がありますが、コミットベースのトリガーを時間ベースのトリガーに置き換えることができます。
ただし、適切な開発プラクティスに従っており、開発者が変更をマージしてコミット前に単体テストを実行する場合、開発者がかかる時間は（長期的には）CIビルドマシンの時間と一致するはずです。
開発者がコードベースの非常に異なる部分で変更を行っている場合、フォローアップ手順は、プロジェクトを複数のサブプロジェクト（ライブラリ）に分割し、それらを個別に編集/テスト/ビルドすることです。
まあ、すべてのコミットに対してCI検証を実行するという提案は、統合をより確定的にするための試みにすぎません。最初に失敗した検証はすぐに障害のあるチェンジセットを指し示すため、ブランチから回復するために行わなければならないのは修復のみです。品質の回帰。
severalチェンジセットが2つの連続する検証の間にコミットされた場合、失敗は原因を含むチェンジセットのグループを示すだけです。修理作業を行う前に、原因を正確に特定するための追加の作業が必要になります。これは通常、固定された/確定的な時間を要しません。そのため、全体的に、回帰によって引き起こされる妨害は長くなります。
すべてのコミット後の検証でさえ、特効薬ではありません。それらは、複数の回帰を引き起こすチェンジセットがお互いに近づきすぎてコミットされない限りのみ効果的です。1つ以上の後続のチェンジセットが検証前にコミットされた場合最初の変更セットが完了し（失敗した結果）、最初の変更セットがバックアウトされ、最初の変更セットをバックアウトしても、ブランチは回帰なしの状態になりません-他の回帰はまだ存在しますが、明確な指示がない可能性があります犯人の、再び長い閉塞に変換されます。
上記は、post-commit検証に基づくCIシステムが高速プロジェクトで輻輳しやすいいくつかの理由にすぎません。詳細については、my Congestion in Traditional CI Systems の投稿を参照してください。 免責事項：私はこの投稿で言及されている会社に関係しています。
最終的にプリコミットベースのCIシステムを検討したい可能性があるを保証するCIツールはありますか？ブランチの品質レベルに回帰はありませんか？