スクラムと安定した開発は矛盾を作りますか？

私は5チーム、合計約40人の開発者からなる開発グループの一員です。私たちは3週間のスプリントでスクラム方法論に従っています。継続的な統合セットアップ（Jenkins）があり、ビルドパイプラインには数時間かかります（広範な自動テストのため）。基本的に、開発プロセスはうまく機能します。

ただし、新しいスプリントを開始してから数日後、ビルドが不安定になり、スプリント終了の「コミットが停止する」まで揺れたままになることがあります。これの悪影響は、パイプラインのはるか下のビルドステップ、特にUI / Webtestsが数日間実行されないことです（「グリーン」ビルドでのみトリガーされるため）。その結果、新しく導入されたバグは、スプリントの非常に遅い段階でのみ検出されることがよくあります。

• 各コミットは、テストの基本セットに対して検証されます。確認されると、コードレビュー後に変更がマスターにプッシュされます（Gerrit）
• 基本的な単体テストは30分ごとに実行され、期間は10分未満です
• 統合テストは2時間ごと、1時間ごとに実行されます
• UI / Webtestsは、成功した統合テストで数時間実行されます

スプリント中のビルドの安定性の責任者（スプリントごとに責任が渡される）によっては、ビルドを安定させるための中間的なアドホックな「コミット停止」が存在する場合があります。

だから、私たちが欲しい：

1. 開発チームは、スプリント中に変更を開発してコミットします
2. 後続のビルド結果にはほとんど意味がないため、ビルドステップが失敗した場合に放棄するビルドプロセス
3. 開発者にタイムリーに質の高いフィードバックを提供するビルドプロセス

（2）を考えると、ポイント（1）と（3）は互いに矛盾しているように見えます。誰もこれに対処する良い方法を持っていますか？

（現在、ポイント（2）を緩めており、失敗したビルドステップでもビルドの継続を許可しています。それが品質にどのように影響するかについて、まだフィードバックがありません。）

ありがとう、サイモン

最初にいくつかの基本原則：-大きな変更は常にVCSの機能ブランチで行う必要があります-機能ブランチはトランクにマージする前にすべてのテストに合格する必要があります。追加 -コミットは常にビルド する必要があります-ビルドが壊れた場合は、コミッターおよび/またはチームの他のメンバーによる即時のアクションが必要です。-失敗したテストは、重要なテストである場合にのみ残りのテストを中止する必要があります。

チームとして、これらのプラクティスに従い、それらを実施する場合：ビルドが壊れたときに「名前と恥」：ビルドを壊す可能性のあるコミットが機能ブランチで行われるので、行ってください。ビルドを壊す他のコミットはすぐに対処する必要があり、その後、ダウンストリームのテスト結果を取得します。

UI / Webテスト用に、午前中に最初に報告する夜間実行として、最新の「成功した」ビルドの自動テスト（必ずしも統合テストに合格するものではない）を追加することもできます。

スクラムとは関係ありません。とにかく、ビルドは常に安定している必要があります。

ローカルビルドを実行し、ユニットテストをローカルで実行しない限り、誰もチェックインする必要はありません（もちろん、両方とも合格します）。ローカルのビルドおよびテストプロセスは変更に敏感である必要があり、変更されていないコードのテストをスキップできます。

ビルドの失敗や単体テストの失敗の原因となるものを紹介した人は誰でも恥ずかしいはずです。ビルドが壊れている場合は、すぐに修正する必要があります。

問題は、テストの実行に時間がかかりすぎることです。幸いなことに、ムーアの法則はその問題の解決策を提供してくれました。今日、ハイエンドサーバーのCPUには10コア（および10ハイパースレッド以上）を簡単に搭載できます。単一のコンピューターに複数のこのようなCPUが存在する場合があります。

これだけ時間がかかるテストがあれば、より多くのハードウェアで問題を解決できます。ハイエンドサーバーを購入し、テストを並列化して、テストがすべてのCPUコアを十分に活用できるようにします。現在のテストがシングルスレッドの場合、10個のコアと10個のHyperThredsを利用すると、おそらくテストの実行が15倍速くなります。もちろん、これは15倍のメモリも使用することを意味するため、コンピューターには十分なRAMが必要です。

したがって、数時間は10〜30分になります。

ビルドにどれくらい時間がかかるかは言わなかったが、makeなどの標準のビルドツールではビルドも並列化できます。単体テストを並列化し、一般的な開発者コンピューターに4つのコアと4つのハイパースレッドがある場合、10分未満の単体テストは2分未満に変わります。それで、おそらく、コミットする前に全員が単体テストを実行するというポリシーを実施できますか？

テストの失敗について、さらにテストを停止する：ビルドサーバーでは実行しないでください！障害について可能な限り多くの情報が必要であり、さらにテストを行うと重要なことが明らかになる場合があります。もちろん、ビルド自体が失敗した場合は、単体テストを実行できません。開発者が自分のマシンで単体テストを実行する場合、最初の失敗で中止することができます。

スクラムとあなたの問題との関係は見当たりません。問題は、開発プロセスで実際に発生する可能性があります。

Jenkinsをさらにインストールし、開発者に別のJenkinsインスタンスをチェックさせることはできませんか？

ここでの最善の解決策は、マスターブランチにチェックインされ、メインのJenkinsインスタンスによってコンパイル/テストされる前に、すべてのテストにコードを渡すことです。ビルドを壊すコードを人々にチェックインさせないでください。

開発ブランチにコードをチェックインし、テストに合格してプルリクエストを作成するかどうかを確認します。ただし、明らかにjenkinsに機能ブランチをプルさせてテストすることができます。

ポイント（2）が最も苦痛なポイントであると思われるので、私はそれに焦点を合わせます。

プロジェクトを複数のモジュールに分割する時が来るかもしれません。

https://en.wikipedia.org/wiki/Dependency_inversion_principle

A.高レベルモジュールは低レベルモジュールに依存しないでください。どちらも抽象化に依存する必要があります。

B.抽象化は詳細に依存するべきではありません。詳細は抽象化に依存する必要があります。

1つのモジュールがビルドに失敗した場合、他のモジュールがインターフェイスに依存し、そのインターフェイスを構成するコードが正常にビルドされている限り、他のモジュールのビルドは続行できます。

これにより、他のビルド障害が発生する可能性についてフィードバックが得られるため、次のビルドが発生する前に複数の破損したモジュールを修正する時間ができます。

一般に、SOLIDの原則は、ライブラリを処理し、問題を構築することを目的としています。言い換えれば、この一連の原則は、あなたが直面している正確な種類の問題を解決するために考案されたものです。

サイドノート（juhistの答えを参照）として、ビルドを別々のモジュールに分割しないと、ビルドを（並列化により）高速に実行できません。

あなたのチームは、スクラムの重要な教義の1つである、完成した、機能するソフトウェアを見逃していると思います。PBIは、チームが確立したDoneの定義に合格するまで、完了とマークされるべきではありません。Doneの定義はチームごとに異なりますが、次のようなものが含まれる可能性があります。

• コードには単体テストがあります
• 自動ビルドの一部としてのユニットテストパス
• コードがメインにマージされました（競合が解決されました）
• 等

ですから、基本的に、実際に行われていないことをチームが完了済みとしてマークしているということです。それ自体が問題です。

それ以外は、適切なバージョン管理管理に要約されます。Gitを使用している場合、すべての作業は開発者のローカルリポジトリで行われ、「完了」して潜在的にリリース可能でない限り、リモートに何かをプッシュすべきではありません。不完全な作業がメインリポジトリにプッシュされることはありません。開発者が長寿命の機能ブランチで作業する必要があり、作業を失うことがないようにリモートにプッシュしたい場合は、フォークから作業する必要があり、その後、そのフォークをメインにマージしますこの機能は「完了」しており、潜在的にリリース可能です。

TFVCの場合、すべてが「リモート」で発生するため、少し複雑です。つまり、簡単な修正でない限り、開発者は常にブランチで作業する必要があります。ただし、ここではGitと同じルールが適用されます。不完全なソフトウェアはコミットされません。限目。適切に管理されたバージョン管理では、「メイン」は常にリリース可能でなければなりません。「メイン」を中断させるコミットが行われた場合、それは正しく行われていません。