ターゲット環境を頻繁に更新する継続的統合プロセスを使用しているため、「変更」があるたびに「すぐに」変更をテストできます。それはCIの目標の一部ですよね？
ただし、管理者や顧客など、テストサイクルに関係する他の人もいると仮定します。他の人にあなたの今後の変更をレビュー（破壊？）させようとするのは理にかなっていますよね？
しかし、他の人々が真剣にテストしようとしている環境で継続的に変更を提供し続けると、次のような複数の問題が発生する可能性があります。
they 問題を報告するのに時間を浪費する可能性があり、（詳細な）レポートを保存するまでに、問題を自分で再現することさえできなくなります（たとえば、誤って同じ問題に遭遇し、環境で既に修正しているため）。you 何らかの問題に遭遇した環境はもはや同一ではないため、彼らが報告した問題を再現できない可能性があります（あなた（!!!）が環境をオーバーレイした可能性があります）。それで、あなたはそのような（イライラする）状況を避けるために何をすることができますか（物事を構成する方法？）
回答:
主にいくつかの答えが必ずしも当てはまらない理由を示しているので、これに関する私の経験をお伝えします。
開始するコンテキスト：
私たちがやっていることは完全な自動化された継続的デリバリーではなく、一般的な運用のために一貫した多くのアプリケーションを立ち上げるためのリリースのスケジュールがあります。これとは別に、各テストチームは、テストしているアプリケーションのQ / A環境の1つでリリースをトリガーし、特定のアプリケーションバージョンをロックして、別のチームリクエストがテストを中断しないようにすることができます。
アプリケーションの依存関係はリリース前にチェックされるため、他のアプリケーションを更新できない場合、または必要な依存関係と一致しない場合、システムは何かをリリースしません。主なアイデアは、誰かに影響が及ばないときに更新を許可することです。テストが計画されていない場合は、以前の環境から流れる必要がありますこの「オンデマンド」メソッドシステムを検証しました）。
短いバージョンでは、環境内のアプリケーションの周りに「セマフォ」システムがあります。チームは、手動テストの間、その依存関係（および推移的な依存関係）でターゲットアプリケーションをロックできる必要があります。
このセマフォの実装は、オートメーションシステムに大きく依存しているため、これについては説明しません。
もちろん、他の人が言ったように、簡単な方法は、上記のセマフォを回避するために、すべての依存関係を持つアプリケーションの新しい環境を作成することです。
すべてのテスト実行で確実に再初期化されることなく、常に再利用されるテスト環境について話しているように聞こえます。これにより、このようなテストは信頼できなくなります。同様に、信頼性の観点から、必要に応じて手動テストを行います。
私見では、あなたは、このようなテストを使用すべきではないの内側に効果的に（その領域に少なくとも）あなたの認定プロセスを無効にすると、あなたのCI / CD資格の目的。提供されたソフトウェアバージョンごとに実際にテストXを実行せずに、またはpass得られた結果が（誤検出による）偶然でないことを確信せずに、ソフトウェアがテストXに合格すると、テストの信頼レベルが低下します。偽陰性は信頼性を損なうものではありませんが、不必要な「ノイズ」が発生するため望ましくありません。
CI / CD認定プロセスの外部でこのようなテストを実行することは問題ありません。ただし、このようなテストで失敗した結果は、顧客が発見したバグのように扱うことになります。問題の修正を開発し、修正が機能していることを確認するには、問題を確実に再現する必要があります。そして、テストが信頼できない場合、あなたは本当にそれをすることはできません。
問題に対処することを計画している場合、理想的には、問題を再現するための自動化された信頼できるテストケースを最初に開発します。修正の開発とその有効性の確認に使用します（テスト結果はFAILからPASSに移行する必要があります）。また、このテストケースをCI / CD認定プロセス内に配置して、必要に応じて将来の再発を防ぐこともできます。これにより、ソフトウェアリリース全体の品質レベルが向上します。
insideoutside
通常のアプローチは、さまざまな環境を作成することです。
DEV-これは開発チームが物事を台無しにする場所です。すべての変更チューニングの作成、新しいバージョンのデプロイなどがあります。CIが完全に統合される場所は次のとおりです。
PREPROD / QA-これは、QA /テスト/検証チームがテストを行う「プレイ」場所です。通常、この環境はテスト中にフリーズします。CIとこの環境の統合は、製品の新しいバージョン、構成などを提供することのみです。
生産-説明する必要があります:)？
Romeo Ninovの答えに追加するには、環境内で可能な限りアプリケーションを分離する必要があります。これが、dockerが開発/テストで非常に成功した理由の一部です。環境をまったく共有していないというふりをしましょう。
もう1つのオプションは、アプリケーションを実行するサーバーを非常に明確に定義し、環境を構成する他のインフラストラクチャとは別にすることです。すなわち。すべての環境管理または使用可能化機構は、別個の長寿命サーバー上にあります。次に、既知のイメージに基づいて新しい短命のサーバーをフックしてアプリケーションをテストし、ベースイメージに変更が加えられた場合、すべての新しいコンポーネントのすべての場所にそれらの変更を適用する必要があります。つまり、すべてに対して変更をテストします。
appdevチームが他の誰かのアプリケーションを破壊する変更を要求し、それが困難な場合、彼らはコード内で緩和策を内部的に作成し、特定の要件を環境提供とは別に保つ必要があります。