凍結テスト環境を実装するにはどうすればよいですか？

「統合によって引き起こされるテスト環境での不安定性を継続的に回避するにはどうすればよいですか？」に関する質問への回答の一部を以下に示します。

通常、この環境はテスト中にフリーズします。

私の質問：凍結環境のサンプル実装は何ですか？つまり、誰もが（リリースマネージャーのような承認されたユーザーによって許可されている場合を除いて）そのようなフリーズされた環境では何も変更できないように技術的に強制するために何ができますか。

明確化：

• 銀行での年末処理中（例）の「凍結期間」とは何ですか（私が思う）について話しているのではありません。それは、年末の処理に影響を与える可能性のある新しい変更/修正が導入されるリスクを軽減するために、実稼働環境に変更を適用することを許可しないことです。

• 変更の承認/適用を許可されているユーザー（私の例のリリースマネージャーなど）は、例外的な場合にのみ変更を行うと想定します。テスト中に重大度の高い問題が発生した場合など、修正を次のリリースに延期することはオプションではありません（そのような修正なしでリリースがアクティブ化されると、本番稼働が危険になるため）。

• これは、テスト中に自動更新を一時停止することに関するだけの可能性があります。重要なのは、別のチームがまだアプリケーションAに依存するバージョンXでアプリケーションBをテストしている間に、誰かがアプリケーションAをバージョンYにアップグレードしないようにすることです。テスト。

質問の文脈での私の答えは、非常に高価なテスト環境（たとえば、メインフレームや非常に大規模な通信機器など）であり、複数のテストで同時に複数のユーザーが共有することが期待されています。

多くの場合、このような機器にはソフトウェア管理システムがあり、特にソフトウェアの（アン）インストール/アップグレード/ダウングレードなどを制御します。どちらかが多かれ少なかれプログラム可能なポリシーに基づいて、そのような操作をブロックするための何らかのメカニズムを持っている必要があります（これは、質問を正しく理解した場合、環境の凍結と同等です）。

そのような場合、テスト環境に必要な望ましい凍結スケジュールをサポートするために、特定のポリシーを正確に作成できます。理想的には自動化され、テスト実行ラッパーやCIシステムなどの外部ソースからの凍結/解凍トリガーを受け入れる。そして、必要と思われる場合は、おそらく人間がトリガーするオーバーライドを使用します。

もちろん、ソフトウェア管理システムのこのような機能は、機器の他のコンポーネントをテストするときに役立ちますが、ソフトウェア管理システム自体のテストには役立ちません。

TeamCityには、複数のビルド定義が依存するリソースを定義できる共有リソースビルド機能があります。ビルド定義には、読み取りロックまたは書き込みロックが必要な場合があります。これらのロックが排他的であるか、ある程度の並列性を許可するかを定義することもできます。

我々は、名前の共有環境について次のように仮定します場合PreProdを：

• 「PreProd」という名前の共有リソースが存在します。
• デプロイメントなど、その環境に変更を加えるすべてのビルド定義は、「PreProd」で排他的な書き込みロックを取得します。
• 非限定的なテストなど、環境で読み取り専用操作を実行するすべてのビルド定義は、「PreProd」で非排他的な読み取りロックを取得します。
• TeamCityは、おそらく別のツールを介しても、PreProdで何でも実行できる唯一のプロセスです。

したがって、次のことが当てはまります。

• 展開が行われると、PreProdを使用できる他のものがなくなり、キューに入れられます。
• テストの実行中は、テストが完了するまで展開がキューに入れられます。

除外プラグインを使用して、Jenkinsで同様のメカニズムを使用できます。実際、この機能は、ロックまたはセマフォを使用して、たとえばApache ZooKeeperやHashiCorp Consulなどのプロセスに組み込むことができます。

これは私には反パターンのように聞こえます。誰もが誰もがすべての環境にアクセスできるべきではないと思います。

ユーザーがプロセスを覆している場合、私はプロセスを真剣に検討して、人々の邪魔にならないようにします。

特定の状態を強制する自動化メカニズムを実装することは、人々が物事を正しい方法で実行するように促すのにも役立ちます。これは、Config Managementを介して、または誰かがSSHで不変のインスタンスを破壊した場合に発生します。