私は200人以上の人がいて、3つの異なる場所にいるという大きな製品を扱っています。ほとんどの人はメインブランチで作業しているので、もちろん、壊れたビルドを無効にすることが重要です。デイリービルドがあり、ビルドの生成には約6時間かかります。「提出する前に注意を払う」というチームの重点を何度も管理しますが、今では1週間で少なくとも1つのビルドが壊れています。
ビルドの失敗を減らすための実践を共有しますか?ありがとう。
私は200人以上の人がいて、3つの異なる場所にいるという大きな製品を扱っています。ほとんどの人はメインブランチで作業しているので、もちろん、壊れたビルドを無効にすることが重要です。デイリービルドがあり、ビルドの生成には約6時間かかります。「提出する前に注意を払う」というチームの重点を何度も管理しますが、今では1週間で少なくとも1つのビルドが壊れています。
ビルドの失敗を減らすための実践を共有しますか?ありがとう。
私が最初にすることは、実際には、ビルドを高速化するために可能な限り努力することです。これの重要性を過小評価することはできません。ビルドを高速化することが、おそらく最速かつ最大の勝利です。少なくともSSDをビルドマシンに配置します。
それはさておき、これが私が行ったのを見たいくつかのことです:
部分ビルド:一部の人はスモークテストとも呼ばれます。高速に実行され、ビルド全体が迅速に失敗する高レベルのテスト。それらは完全なビルドの前に実行されます。
小規模なローカルビルド:多くの人がいるので、プログラマーのセットごとにある種のローカルブランチがあると思います。そこでローカルで実行されるビルドはありますか?
コードをプッシュする前に、開発者が自分のマシンで可能な限り幅広いテストセットを実行するようにしてください。これはすでに起こっています...そうですか?
壊れたビルドはイベントではないはずです。これを実現するには、壊れたビルドに関連するコストを削減する必要があります。これは、作成に6時間かかり、ほとんどの場合、壊れたビルドがすべて不在のときに実行されるためです。 buildは、プロジェクト全体のスケジュールを1日移動できます。このコストを取り除くには、頻繁に構築し、迅速に構築する必要があります。したがって、実行できる最善のことは、ビルド時間を改善し、すべてのチェックインでビルドすることです。