展開環境
展開環境（てんかいかんきょう）、またはデプロイメント環境（デプロイメントかんきょう）（英:Deployment environment）は、ソフトウェアデプロイメントにおける環境または層、コンピュータープログラムまたはソフトウェアコンポーネントが展開、実行されるコンピューターシステムのこと。同じマシン上でプログラムを開発してすぐに実行するなどの単純なケースでは、単一の環境で行う場合があるが、業務用途では、開発環境（変更が最初に行われる場所）と本番環境（エンドユーザーが使用する環境）は分離される。多くの場合、間にいくつかの段階がある。この構造化されたリリース管理プロセスにより、問題が発生した場合の段階的な展開（ロールアウト）、テスト、およびロールバックが可能になる。
それぞれの環境の規模は大幅に異なる場合がある。開発環境は通常、個々の開発者のワークステーションだが、本番環境は、データセンター内の地理的に分散した多くのマシンのネットワーク、またはクラウドコンピューティング内の仮想マシンを使う。コード、データ、および構成は並行して展開できるが、対応する層同士で接続する必要は必ずしもない。たとえば、運用前のコードは運用データベースに接続する場合がある。
アーキテクチャ
編集展開アーキテクチャは大幅に異なるが、大まかに言って、階層は開発環境（DEV）で開始し、本番環境（PROD）で終了する。一般的な4層アーキテクチャは、開発環境、テスト環境、モデル環境、本番環境（DEV、TEST、MODL、PROD）であり、ソフトウェアが順番にそれぞれに展開される。他にも、検収テスト用の品質管理（QC）環境、本番に進むことを意図していない実験用のサンドボックスや実験（EXP）環境、本番環境で問題が発生した場合に即座にフォールバックを提供するディザスタリカバリ環境などがある。もう1つの一般的なアーキテクチャは、開発環境、テスト環境、検収環境、本稼働環境（DTAP）である。
このネーミングは、サーバーがリモートデータセンターで実行されるサーバープログラムに特に適している。アプリケーション（アプリ）やクライアントなどのエンドユーザーのデバイスで実行されるコードの場合、代わりにユーザー環境（USER）またはローカル環境（LOCAL）というネーミングにする。
正確な定義と環境間の境界はさまざまである。テストは開発の一部と見なされる場合があり、受け入れはテストの一部、ステージの一部と見なされる場合、または個別と見なされる場合がある。主な層は順番に進行し、新しいリリースが順番にそれぞれに展開（ロールアウトまたはプッシュ）される[1] [2]。 実験層と回復層が存在する場合、このフローの外側にある。実験リリースは最終版だが、回復は通常、本番環境の古いバージョンまたは複製バージョンであり、本番環境の後に展開される。問題が発生した場合は、古いリリースを新しいリリースであるかのようにプッシュするだけで、古いリリースにロールバックできる。最後のステップである本番環境への展開（「本番環境へのプッシュ」）は、問題が発生するとユーザーにすぐに影響を与えるため、最も気を付けるステップである。このため、これは多くの場合、異なる方法で処理され、少なくともより注意深く監視され、場合によっては段階的なロールアウトがあるか、スイッチを切り替えるだけで迅速なロールバックを可能とする。品質保証（QA）環境のような名前は避けるのが最善である。 QAはソフトウェアテストを意味するものではないからだ。テストは重要だが、QAとは異なる。
展開は、完全なリリースを必要とせずに、主に緊急または比較的小さな変更を提供するために、この通常のプロセスの外で行われることがある。これは、単一のパッチ、大きなサービスパック、または小さな修正プログラムで構成されている場合があります。
環境の規模は大きく異なる可能性がある。開発は通常、個々の開発者のワークステーションだが（数千人の開発者がいる場合もある）、本番環境は地理的に分散した多くのマシンである場合がある。テストとQCは、これらに充てられるリソースに応じて、小規模または大規模になる可能性があり、ステージングは、単一のマシンから本番の正確な複製までさまざまである。
環境
編集次の表は、階層の細かく分割されたリストを示す[要出典] 。
| 環境/層名 | 説明 |
|---|---|
| ローカル | 開発者のデスクトップ/ワークステーション |
| 開発/トランク | 開発者が単体テストを実行できるサンドボックスとして機能する開発サーバー |
| 統合 | CIビルドターゲット、または開発者による副作用のテスト用 |
| テスト/品質管理/内部検収 | インターフェイステストが実行される環境。品質管理チームは、新しいコードが既存の機能に影響を与えないことを確認し、テスト環境に新しいコードを展開した後、システムの主要な機能をテストする。 |
| ステージング/ステージ/モデル/プリプロダクション/外部クライアント検収/デモ | 実稼働環境のミラー |
| 実稼働/本番/ライブ | エンドユーザー/クライアントにサービスを提供 |
開発環境
編集開発環境（dev）は、ソフトウェアへの変更が開発される環境であり、最も単純なのは個々の開発者のワークステーションです。これは、さまざまな点で最終的なターゲット環境とは異なります。ターゲットはデスクトップコンピューターではなく（スマートフォン、組み込みシステム、データセンターのヘッドレスマシンなど）、他の点では類似していても、開発者の環境は異なります。コンパイラ、統合開発環境、ライブラリの異なるバージョンまたは追加バージョン、サポートソフトウェアなど、ユーザーの環境には存在しない開発ツールが含まれます。
特に複数の開発者がいるバージョン管理のコンテキストでは、より細かい区別がなされる。開発者は自分のマシンにソースコードの作業コピーを持ち、変更はリポジトリに送信され、トランクまたはブランチのいずれかにコミットされる。開発方法論。変更が処理されて試行される個々のワークステーション上の環境は、ローカル環境またはサンドボックスと呼ばれる場合がある。クリーンな環境でリポジトリのソースコードのコピーを構築することは、統合（異なる変更の統合）の一部である別個のステップであり、この環境は統合環境または開発環境と呼ばれる場合がある。継続的インテグレーションでは、これはすべてのリビジョンと同じくらい頻繁に行われる。 「リポジトリへの変更をコミットする」というソースコードレベルの概念に続いてトランクまたはブランチをビルドすることは、ローカル（個々の開発者の環境）から統合（クリーンビルド）へのリリースのプッシュに対応する。このステップでの不良リリースは、変更によってビルドが破損したことを意味する。リリースをロールバックすることは、その時点以降のすべての変更をロールバックするか、可能であれば、破損した変更のみを元に戻すことに対応する。
テスト環境
編集テスト環境の目的は、人間のテスターが自動チェックまたは自動化されていない手法のいずれかを介して、新しいコードや変更されたコードを実行できるようにすることである。開発者が開発環境での単体テストを通じて新しいコードと構成を受け入れた後、アイテムは1つ以上のテスト環境に移動される[3]。 テストが失敗すると、テスト環境はテストプラットフォームから障害のあるコードを削除し、担当の開発者に連絡して、詳細なテストと結果のログを提供できる。すべてのテストに合格すると、テスト環境またはテストを制御する継続的インテグレーションフレームワークにより、コードを次の展開環境に自動的にプロモートできる。
さまざまなタイプのテストは、さまざまなタイプのテスト環境を示唆しており、その一部またはすべてを仮想化して[4] 、迅速な並列テストを実行できる。たとえば、自動化されたユーザーインターフェイステスト[5]は、複数の仮想オペレーティングシステムとディスプレイ（実または仮想）で発生する可能性がある。パフォーマンステストでは、パフォーマンステストの結果を経時的に比較できるように、正規化された物理ベースラインハードウェア構成が必要になる場合がある。可用性または耐久性のテストは、仮想ハードウェアおよび仮想ネットワークの障害シミュレーターに依存する場合がある。
テストは、テスト環境の洗練度に応じて、シリアル（次々に）またはパラレル（一度に一部またはすべて）になる。アジャイルおよびその他の生産性の高いソフトウェア開発手法の重要な目標は、ソフトウェアの設計または仕様から本番環境への納品までの時間を短縮することである[6]。 高度に自動化され並列化されたテスト環境は、迅速なソフトウェア開発に大きく貢献する。
ステージング環境
編集ステージング環境、または実稼働前環境は、実稼働環境に正確に類似したテスト用の環境である[7]。 実際の本番環境を可能な限り厳密にミラーリングすることを目的としており、データベースなどの他の本番サービスやデータに接続する場合がある。たとえば、サーバーはローカルではなくリモートマシンで実行され（開発中は開発者のワークステーションで、テスト中は単一のテストマシンで）、システムでのネットワークの影響をテストする。
ステージング環境の主な用途は、本番環境に適用する前に、すべてのインストール/構成/移行スクリプトと手順をテストすることである。これにより、本番環境へのすべてのメジャーおよびマイナーアップグレードが、エラーなしで、最小限の時間で確実に完了する。
ステージング環境のもう1つの重要な用途は、パフォーマンステスト、特に負荷テストである。これは、環境に敏感であることが多いためである。
一部の組織では、ステージング環境を使用して、新機能をプレビューして顧客に触ってもらったり、外部依存関係のライブ環境バージョンとの統合を検証したりする。
実稼働環境
編集実稼働環境は、ユーザーが直接対話する環境であるため、特にサーバーではライブ環境とも呼ばれる。
本番環境への展開は最もデリケートなステップです。これは、新しいコードを直接展開するか（古いコードを上書きするため、一度に1つのコピーしか存在しない）、または構成変更を展開することによって実行できる。これにはさまざまな形式があります。新しいバージョンのコードの並列インストールを展開し、構成を変更してそれらを切り替える。古い動作と機能フラグを使用して新しいバージョンのコードを展開し、フラグフリップを実行する構成変更を使用して新しい動作に切り替える。または、別々のサーバー（1つは古いコードを実行し、もう1つは新しいサーバー）を展開し、トラフィックルーティングレベルで構成を変更して、トラフィックを古いものから新しいものにリダイレクトする。これらは順番に、一度にまたは段階的に行うことができる。
ホットスワップが可能でない限り、新しいリリースをデプロイするには通常、再起動が必要である。したがって、サービスの中断（通常、アプリケーションが再起動されるユーザーソフトウェアの場合）、または冗長性（ロードバランサーの背後でインスタンスをゆっくり再起動するか、起動する）が必要である。事前に新しいサーバーを作成してから、トラフィックを新しいサーバーにリダイレクトするだけである。
新しいリリースを本番環境に展開する場合、すべてのインスタンスまたはユーザーにすぐに展開するのではなく、最初に単一のインスタンスまたは一部のユーザーに展開してから、すべてに展開するか、段階的に展開して、最後のリリースをキャッチすることができます。 -分の問題。これは、実際に本番環境で行われることを除いて、ステージングに似ており、炭鉱での毒ガス検知に由来し、カナリアリリースと呼ばれる。これにより、複数のリリースが同時に実行されるため複雑さが増すため、互換性の問題を回避するために、通常はすぐに終了する。
フレームワークの統合
編集開発環境、ステージング環境、および本番環境は、 ASP.NET Coreの既知の文書化された環境変数となっている。 定義された変数に応じて、異なるコードが実行され、コンテンツがレンダリングされ、異なるセキュリティおよびデバッグ設定が適用される[8]。
関連項目
編集脚注
編集- ^ “Traditional Development/Integration/Staging/Production Practice for Software Development”. Disruptive Library Technology Jester (December 4, 2006). 2020年12月21日閲覧。
- ^ “Development Sandboxes: An Agile 'Best Practice'”. www.agiledata.org. 2020年12月21日閲覧。
- ^ Ellison (2016年6月20日). “Software Testing Environments Best Practices”. Software Testing Magazine. Martinig & Associates. 2016年12月2日閲覧。 “"Once the developer performs the unit test cases, the code will be moved into QA to start testing. Often you will have a few environments for testing. For example you will have one set up for system testing and another that is used for performance testing and yet another that is used for user acceptance testing (UAT). This is caused by the unique needs for each type of testing."”
- ^ Dubie (2008年1月17日). “How to keep virtual test environments in check”. Network World, Inc.. IDG. 2016年12月2日閲覧。 “"Virtual server technology makes it easy for enterprise companies to set up and tear down test environments in which they can ensure applications will run up to par on production servers and client machines."”
- ^ “Use UI Automation To Test Your Code”. Microsoft.com. Microsoft. 2016年12月2日閲覧。 “"Automated tests that drive your application through its user interface (UI) are known as coded UI tests (CUITs). These tests include functional testing of the UI controls. They let you verify that the whole application, including its user interface, is functioning correctly. Coded UI Tests are particularly useful where there is validation or other logic in the user interface, for example in a web page."”
- ^ Heusser (2015年7月7日). “Are you over-testing your software?”. CIO.com. IDG. 2016年12月3日閲覧。 “"Release candidate testing takes too long. For many agile teams, this is the single biggest challenge. Legacy applications start with a test window longer than the sprint."”
- ^ Sharma, Anurag (2018). Test Environment Management. ITSM Press. p. 11. ISBN 9781912651269
- ^ “Use multiple environments in ASP.NET Core” (英語). docs.microsoft.com. 2019年4月5日閲覧。