チームでビルドの安定性を向上させる方法
私たちは、5〜10人の開発者からなるチームであるソフトウェアプロジェクトに取り組んでいます。コードベースはBambooを使用して継続的に統合されます。ユニットテストと統合テスト、そして機能テスト計画も実行するビルドプランがあります。失敗に関するメールは自動的に届きますが、失敗したプランが修正されるまでに数日かかる場合があります。
質問：プロセス/ツールを改善して、人々が障害をより早く修正できるようにするにはどうすればよいですか？どのようなツール/プロセスがありますか？
編集：機能ブランチで作業していますが、Bambooジョブはメインブランチでのみ実行されます。竹が緑色になるまでプッシュを無効にできるGitフックが所定の位置にあります。これを自動化することは解決策になる可能性がありますが、Opsの部分にはいくつかのセキュリティ制約があり、それができない場合があります。
編集：単体テストと統合テストを使用したビルドには20分かかり、機能テスト計画は1日2回スケジュールされ、約2時間続きます
失敗したビルドの通知はすでにあるので、それらを修正することは主に人の問題です。
壊れたビルドは深刻な問題であり、何よりも先に修正する必要があることについて、チームメンバー間で合意を得る必要があります。
ビルドが壊れたままである限り、あなたはそれに同意する必要があります
- 最後に成功したビルドにすべてのコミットが含まれていることが証明されない限り、作業を完了としてマークすることはできません。
- ビルドが失敗する原因となる問題を修正しない限り、mainブランチへの新しいマージはできません。
ビルドが頻繁に中断する場合は、それが発生する理由と実行できる対策を調査する必要があります。
ここでの1つの可能性は、メインブランチにマージされる前に、機能ブランチがBamboo上に構築されるプロセスを配置できるかどうかを確認することです。またはさらに良いことに、マージの予測結果を作成する必要があります。ブランチ/マージのこのビルドが緑色の場合にのみ、実際のマージを実行する必要があります。
問題が検出されるのが早ければ早いほど修正が容易になるため、ビルドプロセスに変更することがいくつかあります。
- すべてのブランチに対してビルドを実行しますおよびプルリクエスト。これには機能ブランチが含まれ、すべての単体テストはそのビルドに対して実行する必要があります。
- Mainブランチに対してのみ、長時間実行される機能テストを保持します
- both機能ブランチとプルリクエストが緑色になるまで、プルリクエストをマージしないようにします。
最後のビットは、壊れたコードがマージされるのを防ぐだけでなく、マージされる前に開発者にブレークを処理するように強制するのに非常に便利です。前進する方法は、開発者がメインブランチからプルし、ステップから外れているパーツを修正してから、新しいプルリクエストを作成することです。
これを初めて自動化したのは、GithubとAppveyor CIでした。実際にマージされる前に、マージによってテストが中断されるかどうかを知っておくと便利です。
それでも頻繁なビルドブレークで問題が発生する場合は、以下を確認できます。
- 問題はずさんな開発ですか、それともコードアーキテクチャは壊れやすいですか？
- たぶんペナルティを導入します。あなたがビルドを壊した場合、私があなたのために働いた最後の会社は$ 1を支払いました。そのお金は、ハッピーアワーなどのチーム構築イベントに使われました。
- コードをアーキテクチャ的に回復力のあるものにする方法を見つけます。