展開環境

ソフトウェアの展開では 、 環境または層は、コンピュータープログラムまたはソフトウェアコンポーネントが展開および実行されるコンピューターシステムです。同じマシンでプログラムを開発してすぐに実行するなどの単純なケースでは、単一の環境が存在する場合がありますが、産業用では開発環境（変更が最初に行われる）と実稼働環境（エンドユーザーが使用するもの）は分離されます;多くの場合、間にいくつかの段階があります。この構造化されたリリース管理プロセスにより、問題が発生した場合の段階的な展開（ロールアウト）、テスト、およびロールバックが可能になります。

環境のサイズは大きく異なる場合があります。通常、開発環境は個々の開発者のワークステーションであり、本番環境はデータセンターの多くの地理的に分散したマシンまたはクラウドコンピューティングの仮想マシンのネットワークです。コード、データ、および構成は並行して展開でき、対応する層に接続する必要はありません。たとえば、運用前のコードは運用データベースに接続できます。

アーキテクチャ

配備アーキテクチャは大きく変化、しかし、広く、階層は（DEV） 開発で始まり、 生産 （PROD）で終了することによりbookendedれます。一般的な4層アーキテクチャは、 開発、テスト、モデル、生産 （DEV、TEST、MODL、PROD）であり、それぞれにソフトウェアが順番に展開されます。他の一般的な環境には、受け入れテストのための品質管理（QC）が含まれます。サンドボックスまたは実験的（EXP）、生産に進むことを意図していない実験の場合。災害復旧。本番環境で問題が発生した場合に即座にフォールバックします。もう1つの一般的なアーキテクチャは、開発、テスト、受け入れ、生産（DTAP）です。

この言語は、サーバーがリモートデータセンターで実行されるサーバープログラムに特に適しています。アプリケーション（アプリ）やクライアントなど、エンドユーザーのデバイスで実行されるコードの場合、代わりにユーザー環境（USER）またはローカル環境（LOCAL）を参照できます。

環境との間の正確な定義との境界は変化する-試験はDEVの一部と考えることができる、受け入れ圧延 （新しいリリースが展開されると、主段を順に介して進行している等、試験の一部、ステージの一部と考えられ、又は別個であることができますアウトまたはプッシュ ）順番にそれぞれに。実験層とリカバリ層（存在する場合）はこのフローの外側にあります。実験リリースは最終的なものであり、リカバリは通常、実稼働後にデプロイされる実稼働の古いバージョンまたは複製バージョンです。問題が発生した場合は、古いリリースを新しいリリースであるかのようにプッシュするだけで、古いリリースにロールバックできます 。最後のステップである実稼働環境への展開（「製品へのプッシュ」）は、問題が発生するとすぐにユーザーに影響を与えるため、最もデリケートです。このため、これは異なる方法で処理されることが多く、少なくともより慎重に監視され、場合によっては段階的にロールアウトするか、スイッチを切り替えるだけで迅速なロールバックが可能になります。品質保証（QA）のような名前を避けるのが最善です。 QAはソフトウェアテストを意味するものではありません。テストは重要ですが、QAとは異なります。

時には、完全なリリースを必要とせずに、主に緊急の変更または比較的小さな変更を提供するために、この通常のプロセスの外で展開が行われることがあります。これは、単一のパッチ、大きなサービスパック、または小さな修正プログラムで構成されます。

環境のサイズは非常に異なる場合があります。通常、開発は個々の開発者のワークステーション（数千人の開発者がいる可能性があります）であり、生産は地理的に分散した多くのマシンです。テストとQCは、これらに充てられるリソースに応じて、小規模または大規模である場合があり、ステージングは​​、単一のマシン（カナリアに類似）から生産の正確な複製までの範囲に及ぶ可能性があります。

環境

次の表は、階層の詳細リストを示しています。

開発

開発環境（dev）は、ソフトウェアの変更が開発される環境であり、最も単純なのは個々の開発者のワークステーションです。これは、さまざまな点で最終的なターゲット環境とは異なります。ターゲットはデスクトップコンピューター（スマートフォン、組み込みシステム、データセンターのヘッドレスマシンなど）ではなく、開発者の環境は同様です。コンパイラ、統合開発環境、ライブラリの異なるバージョンまたは追加バージョン、サポートソフトウェアなどの開発ツールが含まれますが、これらはユーザーの環境にはありません。

特に複数の開発者によるリビジョン管理のコンテキストでは、より細かい区別が引き出されます。開発者はマシンにソースコードの作業コピーを持ち、変更はリポジトリに送信され、トランクまたはブランチのいずれかにコミットされます開発方法論。個々のワークステーション上の環境は、変更が行われ、試行され、 ローカル環境またはサンドボックスと呼ばれる場合があります。クリーンな環境でソースコードのリポジトリのコピーを構築することは、統合の一部であり、統合（異種の変更の統合）の一部であり、この環境は統合環境または開発環境と呼ばれる場合があります 。継続的インテグレーションでは、これは頻繁に、すべての改訂と同じように行われます。 「リポジトリへの変更のコミット」のソースコードレベルの概念は、トランクまたはブランチの構築に続き、ローカル（個々の開発者の環境）から統合（クリーンビルド）へのリリースのプッシュに対応します。このステップでのリリースが悪いということは、変更がビルドを壊したことを意味し、リリースをロールバックすることは、その時点以降のすべての変更をロールバックするか、可能な場合は破壊的な変更のみを元に戻すことに対応します。

テスト中

テスト環境の目的は、人間のテスターが自動化されたチェックまたは非自動化された手法のいずれかを使用して、新しいコードおよび変更されたコードを実行できるようにすることです。開発者が開発環境での単体テストを通じて新しいコードと構成を受け入れた後、アイテムは1つ以上のテスト環境に移動されます。テストが失敗すると、テスト環境はテストプラットフォームから障害のあるコードを削除し、責任のある開発者に連絡し、詳細なテストと結果のログを提供します。すべてのテストに合格すると、テスト環境またはテストを制御する継続的統合フレームワークは、コードを次の展開環境に自動的に昇格させることができます。

さまざまな種類のテストは、さまざまな種類のテスト環境を提案します。これらの一部またはすべてを仮想化して、迅速な並行テストを実行できます。たとえば、自動化されたユーザーインターフェイステストは、複数の仮想オペレーティングシステムとディスプレイ（実際または仮想）で発生する場合があります。パフォーマンステストでは、パフォーマンステストの結果を経時的に比較できるように、正規化された物理ベースラインハードウェア構成が必要になる場合があります。可用性または耐久性のテストは、仮想ハードウェアおよび仮想ネットワークの障害シミュレーターに依存する場合があります。

テストは、テスト環境の洗練度に応じて、シリアル（次々に）またはパラレル（一部またはすべてを同時に）になります。アジャイルおよびその他の生産性の高いソフトウェア開発プラクティスの重要な目標は、ソフトウェアの設計または仕様から実稼働での配信までの時間を短縮することです。高度に自動化され並列化されたテスト環境は、迅速なソフトウェア開発に重要な貢献者です。

ステージング

ステージングまたはステージング環境とは、実稼働環境とまったく同じテスト用の環境です。実際の本番環境をできる限り厳密にミラー化することを目指しており、他の本番サービスやデータベースなどのデータに接続できます。たとえば、サーバーはローカルではなく（開発中に開発者のワークステーション上で、テスト中に単一のテストマシン上で）リモートシステム上で実行され、システム上のネットワークの影響をテストします。

ステージング環境の主な用途は、すべてのインストール/構成/移行スクリプトと手順をテストしてから、運用環境に適用することです。これにより、実稼働環境へのすべてのメジャーおよびマイナーアップグレードが、エラーなしで、最小限の時間で確実に完了します。

ステージングのもう1つの重要な用途は、パフォーマンステスト、特に負荷テストです。これは、環境に敏感なことが多いためです。

一部の組織では、ステージングを使用して、顧客を選択するための新機能をプレビューしたり、外部依存関係のライブバージョンとの統合を検証したりします。

製造

本番環境は、ユーザーが直接やり取りする環境であるため、特にサーバーではliveとも呼ばれます。

本番環境への展開は最もデリケートな手順です。新しいコードを直接展開する（古いコードを上書きするため、一度に1つのコピーのみが存在する）か、構成の変更を展開することで実行できます。これにはさまざまな形式があります。新しいバージョンのコードの並行インストールを展開し、構成を変更してそれらを切り替える。古い動作と機能フラグを使用して新しいバージョンのコードを展開し、フラグの反転を実行する構成変更を使用して新しい動作に切り替えます。または、別々のサーバー（古いコードを実行するサーバーと新しいコードを実行するサーバー）を展開し、トラフィックルーティングレベルで構成を変更して、古いサーバーから新しいサーバーにトラフィックをリダイレクトします。これらは順番に、一度にすべて実行することも、段階的に実行することもできます。

通常、新しいリリースをデプロイするには、ホットスワップが可能でない限り再起動が必要であるため、サービスの中断（通常はアプリケーションが再起動されるユーザーソフトウェアの場合）または冗長性-ロードバランサーの背後でインスタンスをゆっくり再起動するか、起動する必要があります新しいサーバーを事前に用意し、トラフィックを新しいサーバーにリダイレクトするだけです。

すべてのインスタンスまたはユーザーにすぐに展開するのではなく、本番環境に新しいリリースを展開する場合、最初に単一のインスタンスまたはユーザーの一部に展開し、その後、すべてを展開するか、段階的に展開して最後をキャッチすることができます分の問題。これは、実際に生産で行われることを除いて、ステージングに似ており、石炭採掘と同様に、 カナリアリリースと呼ばれます。これにより、複数のリリースが同時に実行されるため、複雑さが増すため、通常は互換性の問題を回避するためにすぐに終了します。

フレームワークの統合

開発、ステージング、およびプロダクションは、ASP.NET Coreの既知の文書化された環境変数です。定義された変数に応じて、異なるコードが実行され、コンテンツがレンダリングされ、異なるセキュリティ設定とデバッグ設定が適用されます。