スクラムと安定した開発は矛盾を引き起こしていますか？
私は5つのチーム、合計で約40人の開発者を抱える開発グループの一員です。私たちは3週間のスプリントでスクラム方法論に従っています。継続的な統合セットアップ（Jenkins）があり、ビルドパイプラインには数時間かかります（広範な自動テストのため）。基本的に、開発プロセスはうまく機能します。
ただし、新しいスプリントに数日後、ビルドが不安定になり、スプリント終了の「コミットストップ」まで不安定な状態が続くことがわかります。これの悪影響は、パイプラインのはるか下のビルドステップ、特にUI-/Webtestsがnotが数日間実行されることです（「グリーン」ビルドでのみトリガーされるため）。その結果、新しく導入されたバグは、スプリントの非常に遅い段階でのみ検出されることがよくあります。
- 各コミットは、基本的なテストセットに対して検証されます。検証されると、コードレビュー後に変更がマスターにプッシュされます（Gerrit）
- 基本ユニットテストは30分ごとに実行され、所要時間は10分未満です
- 統合テストは2時間ごとに実行され、期間は1時間です
- UI-/Webtestsは、成功した統合テストで数時間実行されます
スプリント中のビルドの安定性の責任者（その責任はスプリントごとに渡されます）によっては、ビルドを安定状態に戻すための中間の臨時の「コミット停止」が存在する場合があります。
だから、私たちは欲しい：
- 私たちの開発チームは、障害のないスプリント中に変更を開発してコミットします
- 後続のビルド結果にはほとんど意味がないため、ビルドステップが失敗した場合に破棄するビルドプロセス
- 開発者に質の高いフィードバックをタイムリーに提供するための構築プロセス
（2）を考えると、ポイント（1）と（3）は互いに矛盾しているようです。誰もがこれに対処する良い方法を持っていますか？
（現在、ポイント（2）を緩和しており、失敗したビルドステップでもビルドの継続を許可しています。品質にどのように影響するかはまだフィードバックがありません）
ありがとう、サイモン
最初にいくつかの基本原則：-大きな変更は常にVCSの機能ブランチで行う必要があります-機能ブランチはトランクにマージする前にallテストに合格する必要がありますAdded-コミットは常にbuild-壊れたビルドにはimmediateコミッターからのアクションが必要&& /またはチームの他のメンバー。 -失敗したテストは、それがクリティカルテストである場合にのみ、残りのテストを中止する必要があります。
チームとして、これらのプラクティスに従い、それらを実施する場合（例：ビルドが壊れたときに「名前と恥」）、ビルドを壊す可能性のあるコミットは機能ブランチにあるため、実行することをお勧めします。ビルドを壊す他のコミットはすぐに対処する必要があり、それからダウンストリームのテスト結果を取得します。
最新の「成功した」ビルドの自動テストを追加することもできます（統合テストに合格する必要はありません）UI/Webテスト用朝の最初のものを報告する夜通しの実行として。
スクラムとは何の関係もありません。ビルドは、関係なく継続的に安定している必要があります。
ローカルビルドを実行してユニットテストをローカルで実行した場合（そして両方とももちろん成功した場合）を除き、誰も何もチェックインしないでください。ローカルのビルドおよびテストプロセスは変更に敏感である必要があり、変更されていないコードのテストをスキップできます。
ビルドが失敗したり、ユニットテストが失敗したりする原因となるものを導入する人は、誰でも 公に恥をかく である必要があります。ビルドが壊れている場合は、すぐに修正する必要があります。
問題は、テストの実行に時間がかかりすぎることです。幸い、ムーアの法則により、この問題に対する解決策が提供されました。今日、ハイエンドサーバーのCPUは、10個を超えるコア（および10個を超えるハイパースレッド）を簡単に持つことができます。 1台のコンピューターにこのようなCPUが複数ある場合があります。
これほど時間がかかるテストがあれば、より多くのハードウェアで問題を解決します。ハイエンドサーバーを購入し、テストを並列化して、テストがすべてのCPUコアを十分に活用できるようにします。今日のテストがシングルスレッドの場合、10コアと10 HyperThredを利用すると、テストの実行が15倍速くなるでしょう。もちろん、これはメモリも15倍使用することを意味するため、コンピュータには十分なRAMが必要です。
したがって、数時間は10〜30分になります。
ビルドにかかる時間は言いませんでしたが、makeなどの標準的なビルドツールでは、ビルドも並列化できます。単体テストを並列化し、一般的な開発者コンピューターに4つのコアと4つのハイパースレッドがある場合、10分未満の単体テストは2分未満になります。それで、おそらくあなたはコミットする前に誰もがユニットテストを実行すべきであるというポリシーを実施することができますか？
テストの失敗についてさらにテストを停止する：ビルドサーバーでそれを行わないでください！障害について可能な限り多くの情報が必要であり、さらにテストを行うと重要なことが明らかになる場合があります。もちろん、ビルド自体が失敗した場合は、単体テストを実行できません。開発者が自分のマシンで単体テストを実行する場合、最初の失敗で中止することをお勧めします。
スクラムとあなたの問題との間に関連は見られません。問題は、実際の開発プロセスで発生する可能性があります。
Jenkinsをさらにインストールして、開発者に別のJenkinsインスタンスをチェックさせることはできませんか？
ここでの最良の解決策は、masterブランチにチェックインされ、メインのJenkinsインスタンスによってコンパイル/テストされる前に、コードがすべてのテストに合格することだと思います。ビルドを中断させるコードをチェックインさせないでください。
コードを開発ブランチにチェックインし、テストに合格するかどうかを確認して、プルリクエストを作成します。しかし、明らかにjenkinsに機能ブランチをプルさせ、それをテストさせることができます。
ポイント（2）が一番つらいポイントのようですので、ここで注目します。
プロジェクトを複数のモジュールに分割するときかもしれません。
https://en.wikipedia.org/wiki/Dependency_inversion_principle
A.高レベルのモジュールは、低レベルのモジュールに依存するべきではありません。どちらも抽象化に依存する必要があります。
B.抽象化は詳細に依存すべきではありません。詳細は抽象化に依存する必要があります。
1つのモジュールがビルドに失敗した場合、他のモジュールがインターフェースに依存でき、そのインターフェースを構成するコードが正常にビルドされている限り、他のモジュールのビルドを続行できます。
これにより、他にどのようなビルドエラーが発生する可能性があるかについてのフィードバックが得られるため、次のビルドが行われる前に、複数の壊れたモジュールを修正する時間があります。
一般的に、SOLID=原則は、ライブラリを処理して問題を構築するために考えられています。つまり、この原則のセットは、直面している問題の正確な種類を解決するために考えられています。
補足として（juhistの回答を参照）、ビルドを個別のモジュールに分割しないと、ビルドを（並列化によって）より速く実行することはできません。
私はあなたのチームがスクラムの重要な原則の1つを欠いていると思います。 PBIは、チームが確立した完了の定義を通過するまで、完了としてマークしないでください。完了の定義はチームごとに異なりますが、おそらく次のようなものが含まれます。
- コードには単体テストがあります
- 自動ビルドの一部としてのユニットテストパス
- コードがメインにマージされました（競合が解決されました）
- 等.
つまり、基本的には、チームが実際に完了したことをマークしているということですnot完了。それ自体の問題です。
それ以外は、適切なバージョン管理管理に要約されます。 Gitを使用している場合、すべての作業は開発者のローカルリポジトリで行われ、「完了」し、解放できる可能性がない限り、リモートに何かをプッシュするべきではありません。不完全な作業をメインリポジトリにプッシュしないでください。開発者がより長寿命の機能ブランチで作業する必要があり、リモートにプッシュして作業が失われないことを確認したい場合、彼らはフォークから作業しているはずであり、その後、そのフォークをメインにマージします機能は「完了」しており、リリースできる可能性があります-以前はできません。
TFVCの場合、すべてが「リモート」で発生するため、少し複雑になります。つまり、迅速な修正でない限り、開発者は常にブランチから作業する必要があります。ただし、ここではGitと同じルールが適用されます。不完全なソフトウェアはコミットされません。限目。適切に管理されたバージョン管理では、「メイン」は常に解放可能である必要があります。 「メイン」を停止するコミットが行われた場合は、正しく実行されていません。