4
事前検証された変更が正常に行われると、捕捉されるべきであった回帰がどのように引き起こされるのでしょうか？
CIのコンテキストでは、統合ブランチの品質レベルを上げるために一般的に使用される指標の1つは、コミット前の品質検証の必須セットです（通常、一部のアーティファクトの構築、ユニットテストの実行、さらには機能/統合テストの一部も含まれます）。 ただし、CIシステム検証では、これらの必須の事前コミット検証でカバーされると想定されていた領域で、一部の回帰（ビルドの破損、さまざまなテストの失敗）が検出されます。 これらの回帰の分析中によく聞かれる議論は、回帰の根本原因として識別された変更をコミットした開発者が、そのようなすべての検証に成功したというものです。そして多くの場合、この主張は次のことを示す確固たる証拠によって裏付けられています。 変更の最終バージョンに達した後、ブランチの先端に基づいて新しいワークスペースに移植されました 必要なアーティファクトはゼロからビルドされました（そのため、ビルドは完全に問題なく、キャッシュ関連の問題などはありませんでした） 問題の領域をカバーし、回帰を検出する必要があるものを含む、すべての必須テストに合格 断続的な誤検知はそれぞれの検証に影響しません ブランチへの変更をコミットするときにファイルのマージは検出されませんでした 新しいワークスペースがプルされたため、変更されているファイルのいずれもブランチでコミットされた他の変更の影響を受けなかった 規定されたすべてのプロセスと実践に正しく従っているにもかかわらず、ソフトウェアの変更がそのような退行を引き起こすことは本当に可能ですか？どうやって？