展開環境

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

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

テスト環境の目的は、人間のテスターが自動チェックまたは非自動化手法のいずれかを使用して、新規および変更されたコードをテストできるようにすることです。開発者が開発環境での単体テストを通じて新しいコードと構成を承認すると、項目は 1 つ以上のテスト環境に移動されます。^{[ 3 ]}テストが失敗した場合、テスト環境は、テスト プラットフォームから欠陥のあるコードを削除し、担当の開発者に連絡し、詳細なテストと結果のログを提供できます。すべてのテストが合格した場合、テスト環境またはテストを制御する継続的インテグレーションフレームワークは、コードを自動的に次のデプロイメント 環境に昇格させることができます。

テストの種類によって必要なテスト環境も異なり、その一部または全部を仮想化することで、迅速かつ並列なテストが可能になります^{[ 4 ]}。例えば、自動化されたユーザーインターフェーステスト^{[ 5 ]}は、複数の仮想オペレーティングシステムやディスプレイ（実機または仮想）で実行できます。パフォーマンステストでは、パフォーマンステストの結果を時系列で比較できるように、標準化された物理的なベースラインハードウェア構成が必要になる場合があります。可用性テストや耐久性テストでは、仮想ハードウェアや仮想ネットワークの障害シミュレータに依存する場合があります。

テストは、テスト環境の高度さに応じて、直列（1つずつ順番に実行）または並列（一部または全部を同時に実行）で行われる場合があります。アジャイルやその他の高生産性ソフトウェア開発手法の重要な目標は、ソフトウェアの設計または仕様から本番環境への納品までの時間を短縮することです。^{[ 6 ]}高度に自動化され並列化されたテスト環境は、迅速なソフトウェア開発に大きく貢献します。

ステージング環境またはプレプロダクション環境は、本番環境と全く同じテスト環境です。^{[ 7 ]}実際の本番環境をできる限り忠実に再現することを目指しており、データベースなどの他の本番サービスやデータに接続できます。たとえば、サーバーはローカルではなくリモートマシンで実行され（開発中は開発者のワークステーション、テスト中は単一のテストマシンなど）、ネットワークがシステムに与える影響をテストします。

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

ステージングのもう一つの重要な用途は、パフォーマンス テスト、特に負荷テストです。負荷テストは、環境に大きく左右されることが多いためです。

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

本番環境は、特にサーバーにおいては、ユーザーが直接やり取りする環境であるため、「ライブ」とも呼ばれます。

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

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

新しいリリースを本番環境に展開する際、すべてのインスタンスやユーザーに即座に展開するのではなく、まず単一のインスタンスまたは一部のユーザーに展開し、その後、すべてに展開するか、段階的に展開することで、直前の問題を早期に発見することができます。これはステージングに似ていますが、実際に本番環境で行われる点が異なります。石炭採掘になぞらえて、カナリアリリースと呼ばれます。複数のリリースが同時に実行されるため複雑さが増しますが、互換性の問題を避けるため、通常は短時間で完了します。