事前検証された変更が正常に行われると、捕捉されるべきであった回帰がどのように引き起こされるのでしょうか？

CIのコンテキストでは、統合ブランチの品質レベルを上げるために一般的に使用される指標の1つは、コミット前の品質検証の必須セットです（通常、一部のアーティファクトの構築、ユニットテストの実行、さらには機能/統合テストの一部も含まれます）。

ただし、CIシステム検証では、これらの必須の事前コミット検証でカバーされると想定されていた領域で、一部の回帰（ビルドの破損、さまざまなテストの失敗）が検出されます。

これらの回帰の分析中によく聞かれる議論は、回帰の根本原因として識別された変更をコミットした開発者が、そのようなすべての検証に成功したというものです。そして多くの場合、この主張は次のことを示す確固たる証拠によって裏付けられています。

• 変更の最終バージョンに達した後、ブランチの先端に基づいて新しいワークスペースに移植されました
• 必要なアーティファクトはゼロからビルドされました（そのため、ビルドは完全に問題なく、キャッシュ関連の問題などはありませんでした）
• 問題の領域をカバーし、回帰を検出する必要があるものを含む、すべての必須テストに合格
• 断続的な誤検知はそれぞれの検証に影響しません
• ブランチへの変更をコミットするときにファイルのマージは検出されませんでした
• 新しいワークスペースがプルされたため、変更されているファイルのいずれもブランチでコミットされた他の変更の影響を受けなかった

規定されたすべてのプロセスと実践に正しく従っているにもかかわらず、ソフトウェアの変更がそのような退行を引き起こすことは本当に可能ですか？どうやって？

開発者が独自のワークステーションで作業しているときに、インフラストラクチャがまったく同じイメージを使用していないワークステーションで仮想ボックスを実行するために焼き付けられたイメージがある場合、私は考えられる1つの可能性があります。

開発者は、機能の開発中に、JVMパラメータやその他の変更をミドルウェアに追加して、作業の初期段階でそれを忘れる必要があります。

コミットする前に、そのワークステーションで実行されるすべてのユニット/統合テストは適切に機能します。ベイクされたイメージが共有されるため、すべてのdevelloperシステムで機能します。

しかし、CIを実行すると、ミドルウェアへの変更が実装されなかったために失敗しました。開発者がそれを要求するのを忘れたか、ベースイメージ/プロビジョニングシステムの更新を担当するチームが持っていなかったためです。時間またはシステムを更新するのを忘れていました。

これは、システムが期待どおりに動作しないことを本番稼働の前の早い段階で通知するため、CIでうまく機能しませんが、欠落しているパラメーターを見つけるのが難しい場合があります。

この最後のポイントは、コミットの拒否を回避し、機能ブランチでCIを中断するだけであるため、他のユーザーをブロックせず、変更が必要なときに開発者が問題を早期に修正して、この変更が忘れられるのを防ぎます流れ。

FWIW、私たちはここでこれを正確に行いました。開発者は開発マシンに完全にアクセスでき、Q / Aのリリースはパラメーターの変更が忘れられたため失敗しました。ミドルウェア（今はTomcat）の構成を処理するためにchefに移動しました。インフラストラクチャの変更はどこかにコーディングする必要があり、すべての環境で再現されます。

もちろんそうだ。生産は常に異なります。リアルマネー。実負荷。実際のユーザー。本当の痛み。これが、重要な変更を機能フラグの背後に置くことが非常に重要である理由です。デプロイメントによって何も変更されないはずです。機能をオンにすることだけが、サイトに大きな変更を加える必要があります。

開発者が行うコミット前の検証は個別に行われるため、並行して検証される他の処理中の変更を考慮に入れることができないため、理論的には破損が常に発生する可能性があります。このような変更は相互に干渉し、SCMレベルで実際に衝突を検出することなく回帰を引き起こす可能性があります。

そのような干渉する変更の簡単な例：

プロジェクトブランチの最新バージョンのコードに、1つのファイルで定義され、他のいくつかのファイルで呼び出される特定の関数が含まれていると仮定します。そのプロジェクトで並行して作業している2人の開発者が、コードに変更を加える準備をしています。

開発者Aは、必須の関数引数を削除または追加する関数を作り直し、もちろん、関連するすべてのファイル内の関数のすべての呼び出しを更新して、更新された定義と一致させます。

開発者Bは、以前にそのような呼び出しが含まれていなかったため、開発者Aの変更の影響を受けないファイルに、この関数の呼び出しを追加することを決定します。もちろん、開発者Bは、最新のラベルに表示される関数の定義と一致するように引数リストを埋めています。開発者Aの変更はまだコミットされていないため、これは古い定義です。

どちらの開発者も、パス結果を使用してコミット前の検証を正しく実行し、コードの変更をコミットします。2つのチェンジセットは同じファイルに触れないため、最終的なマージは行われません。これは通常、潜在的な問題の兆候であり、詳しく調べて、おそらくコミット前の検証を再実行することを保証します。何かがうまくいかないかもしれないという微妙なヒントを与えることはできません。

しかし、最終的な結果は壊滅的です-開発者Bによって追加された関数呼び出しが開発者Aによって更新された関数定義と一致しないため、ビルドが失敗します。

このタイプの問題を見つけたら、これらの問題を誘発する可能性のある新しい非常に迅速に実行される受け入れテストをいくつか作成し、統合テストの前に実行するビルド検証テストに追加する必要があります。常に左にシフトし、変更をコミットする開発者へのフィードバックループを短くする必要があります。これを行う方法が見つからない場合は、おそらくアーキテクチャが必要なほど俊敏ではありません。

@Dan Cornilescu-シナリオは密結合アーキテクチャに有効です。そのため、高パフォーマンスの組織における現在のベストプラクティスとして、疎結合アーキテクチャ（バージョン付きRESTful APIのマイクロサービス）が登場しました。ただし、これらのサービスマトリックスには、克服すべき他の複雑さがあります。

このような問題を克服するために、アーキテクチャ全体をリファクタリングする必要がある場合があります。以前のアーキテクチャに課せられていた制約のため、プラットフォームを5回（10年程度の期間で）完全に再設計したのは、GoogleとeBayの両方だったと思います。