アプリケーション ライフサイクル管理: 開発から本稼働まで

  • [アーティクル]

作成者: Jason Lee

このトピックでは、架空の会社が、継続的な開発プロセスの一環として、テスト、ステージング、および運用環境を通じて ASP.NET Web アプリケーションの展開を管理する方法について説明します。 このトピック全体を通して、特定のタスクを実行する方法に関する詳細情報とチュートリアルへのリンクが提供されています。

このトピックは、企業での Web 配置に関する一連のチュートリアルの概要を提供するように設計されています。 ここで説明する概念の一部を理解していなくても心配しないでください。後に続くチュートリアルで、これらすべてのタスクと手法に関する詳細情報を提供します。

Note

わかりやすくするために、このトピックでは、デプロイ プロセスの一環としてのデータベースの更新については説明しません。 ただし、データベース機能の増分更新は、多くのエンタープライズ展開シナリオの要件であり、このチュートリアル シリーズの後半でこれを実現する方法に関するガイダンスを参照できます。 詳細については、「データベース プロジェクトの配置」を参照してください。

概要

ここで示すデプロイ プロセスは、「エンタープライズ Web 展開: シナリオの概要」で説明されている Fabrikam, Inc. のデプロイ シナリオに基づいています。 このトピックを学習する前に、シナリオの概要をお読みください。 基本的に、このシナリオでは、組織が一般的なエンタープライズ環境のさまざまなフェーズを通じて、合理的に複雑な Web アプリケーションである Contact Manager ソリューションの展開をどのように管理するかを説明します。

大まかに言えば、Contact Manager ソリューションは、開発と展開のプロセスの一環として、次の段階を経ます:

  1. 開発者は、いくつかのコードを Team Foundation Server (TFS) 2010 にチェックインします。
  2. TFS はコードをビルドし、チーム プロジェクトに関連付けられているすべての単体テストを実行します。
  3. TFS は、ソリューションをテスト環境に配置します。
  4. 開発者チームは、テスト環境でソリューションを確認し、検証します。
  5. ステージング環境管理者は、ステージング環境への "what if" 配置を実行して、配置によって問題が発生するかどうかを確認します。
  6. ステージング環境管理者は、ステージング環境へのライブ デプロイを実行します。
  7. このソリューションでは、ステージング環境でユーザー受け入れテストが行われます。
  8. Web 展開パッケージは、運用環境に手動でインポートされます。

これらのステージは、継続的な開発サイクルの一部を形成します。

These stages form part of a continuous development cycle.

各ステージをより詳しく見るとわかるように、実際のプロセスはこれより少し複雑です。 Fabrikam, Inc. では、ターゲット環境ごとに異なるアプローチを使用してデプロイします。

Fabrikam, Inc. uses a different approach to deployment for each target environment.

このトピックの残りの部分では、このデプロイ ライフサイクルの次の主要なステージについて説明します:

  • 前提条件: デプロイ ロジックを配置する前に、サーバー インフラストラクチャの必要な構成をする方法。
  • 初期開発とデプロイ: ソリューションを初めてデプロイする前に行う必要がある操作。
  • テスト環境へのデプロイ: 開発者が新しいコードをチェックインしたときに、テスト環境にコンテンツを自動的にパッケージ化してデプロイする方法。
  • ステージングへのデプロイ: 特定のビルドをステージング環境にデプロイする方法と、デプロイで問題が発生しないように "what if" デプロイを実行する方法。
  • 運用環境へのデプロイ: ネットワーク インフラストラクチャがリモート展開を妨げるときに、Web パッケージを運用環境にインポートする方法。

前提条件

展開シナリオの最初のタスクは、サーバー インフラストラクチャが展開ツールと手法の要件を満たしていることを確認することです。 この場合、Fabrikam, Inc. は次のようにサーバー インフラストラクチャを構成しています:

初期開発と展開

Fabrikam, Inc. 開発チームが初めて Contact Manager ソリューションを展開するには、次のタスクを実行する必要があります:

  • TFS で新しいチーム プロジェクトを作成します。
  • 配置ロジックを含む Microsoft Build Engine (MSBuild) プロジェクト ファイルを作成します。
  • デプロイ プロセスをトリガーする TFS ビルド定義を作成します。

新しいチーム プロジェクトを作成する

  • TFS 管理者の Rob Walters は、「TFS でのチーム プロジェクトの作成」の説明に従って、アプリケーションの新しいチーム プロジェクトを作成します。 次に、リード デベロッパーの Matt Hink がスケルトン ソリューションを作成します。 「ソース管理へのコンテンツの追加」の説明に従って、ファイルを TFS の新しいチーム プロジェクトにチェックインします。

デプロイ ロジックを作成する

Matt Hink は、「プロジェクト ファイルについて」で説明されている分割プロジェクト ファイル アプローチを使用して、さまざまなカスタム MSBuild プロジェクト ファイルを作成します。 Matt は次を作成します:

  • 配置プロセスを実行する Publish.proj という名前のプロジェクト ファイル。 このファイルには、ソリューション内のプロジェクトをビルドし、Web パッケージを作成し、宛先サーバー環境にパッケージをデプロイする MSBuild ターゲットが含まれています。
  • Env-Dev.proj および Env-Stage.proj という名前の環境固有のプロジェクト ファイル。 これには、接続文字列、サービス エンドポイント、Web パッケージを受信するリモート サービスの詳細など、それぞれテスト環境とステージング環境に固有の設定が含まれます。 特定の宛先環境に適した設定の選択に関するガイダンスについては、「ターゲット環境の展開プロパティの構成」を参照してください。

デプロイを実行するために、ユーザーは MSBuild または Team Build を使用して Publish.proj ファイルを実行し、関連する環境固有のプロジェクト ファイル (Env-Dev.proj または Env-Stage.proj) の場所をコマンド ライン引数として指定します。 次に、Publish.proj ファイルによって環境固有のプロジェクト ファイルがインポートされ、各ターゲット環境に対する発行手順の完全なセットが作成されます。

Note

これらのカスタム プロジェクト ファイルの動作方法は、MSBuild の呼び出しに使用するメカニズムとは無関係です。 たとえば、「プロジェクト ファイルについて」の説明に従って、MSBuild コマンド ラインを直接使用できます。 「配置コマンド ファイルの作成と実行」の説明に従って、コマンド ファイルからプロジェクト ファイルを実行できます。 または、「配置をサポートするビルド定義の作成」の説明に従って、TFS のビルド定義からプロジェクト ファイルを実行することもできます。
いずれの場合も、最終的な結果は同じです。MSBuild はマージされたプロジェクト ファイルを実行し、ソリューションをターゲット環境にデプロイします。 これにより、発行プロセスをトリガーする方法の柔軟性が大幅に向上します。

カスタム プロジェクト ファイルを作成すると、Matt はそれらをソリューション フォルダーに追加し、ソース管理にチェックインします。

ビルド定義の作成

最後の準備タスクとして、Matt と Rob は協力して、新しいチーム プロジェクト用の 3 つのビルド定義を作成します:

  • DeployToTest。 これにより、Contact Manager ソリューションがビルドされ、チェックインが発生するたびにテスト環境にデプロイされます。
  • DeployToStaging。 これにより、開発者がビルドをキューに入れると、指定した前のビルドからステージング環境にリソースがデプロイされます。
  • DeployToStaging-WhatIf。 これにより、開発者がビルドをキューに入れると、ステージング環境への "what if" デプロイが実行されます。

以下のセクションでは、これらの各ビルド定義について詳しく説明します。

テスト環境へのデプロイ

Fabrikam, Inc. の開発チームは、確認と検証、ユーザビリティ テスト、互換性テスト、アドホックまたは探索的テストなど、さまざまなソフトウェア テスト アクティビティを実施するためのテスト環境を維持しています。

開発チームは、DeployToTest という名前のビルド定義を TFS に作成しました。 このビルド定義では、継続的インテグレーション トリガーが使用されます。つまり、Fabrikam, Inc. 開発チームのメンバーがチェックインを実行するたびにビルド プロセスが実行されます。 ビルドがトリガーされると、ビルド定義は次を実行します:

  • ContactManager.sln ソリューションをビルドします。 これにより、ソリューション内のすべてのプロジェクトがビルドされます。
  • ソリューション フォルダー構造で単体テストを実行します (ソリューションが正常にビルドされた場合)。
  • デプロイ プロセスを制御するカスタム プロジェクト ファイルを実行します (ソリューションが正常にビルドされ、単体テストに合格した場合)。

最終的な結果として、ソリューションが正常にビルドされ、単体テストに合格すると、Web パッケージとその他のデプロイ リソースがテスト環境にデプロイされます。

The end result is that if the solution builds successfully and passes unit tests, the web packages and any other deployment resources are deployed to the test environment.

配置プロセスのしくみとは?

DeployToTest ビルド定義は、次の引数を MSBuild に提供します:

/p:DeployOnBuild=true;DeployTarget=package;TargetEnvPropsFile=[path]\Env-Dev.proj

DeployOnBuild=true および DeployTarget=package プロパティは、Team Build がソリューション内でプロジェクトをビルドするときに使用されます。 プロジェクトが Web アプリケーション プロジェクトの場合、これらのプロパティは、プロジェクトの Web 配置パッケージを作成するように MSBuild に指示します。 TargetEnvPropsFile プロパティは、インポートする環境固有のプロジェクト ファイルの場所を Publish.proj ファイルに指示します。

Note

このようなビルド定義を作成する方法の詳細なチュートリアルについては、「配置をサポートするビルド定義の作成」を参照してください。

Publish.proj ファイルには、ソリューション内の各プロジェクトをビルドするターゲットが含まれています。 ただし、Team Build でファイルを実行している場合は、これらのビルド ターゲットをスキップする条件付きロジックも含まれます。 これにより、単体テストを実行する機能など、Team Build で提供される追加のビルド機能を利用できます。 ソリューションのビルドまたは単体テストが失敗した場合、 Publish.proj ファイルは実行されず、アプリケーションはデプロイされません。

条件付きロジックは、BuildingInTeamBuild プロパティを評価することによって実現されます。 これは、Team Build を使用してプロジェクトをビルドするときに自動的に true に設定される MSBuild プロパティです。

ステージングへのデプロイ

ビルドがテスト環境で開発者チームのすべての要件を満たしている場合、チームは同じビルドをステージング環境にデプロイできます。 ステージング環境は、通常、サーバーの仕様、オペレーティング システムとソフトウェア、ネットワーク構成などの観点から、運用環境または "ライブ" 環境の特性にできるだけ近い形式で構成されます。 ステージング環境は、ロード テスト、ユーザー受け入れテスト、広範な内部レビューによく使用されます。 ビルドは、ビルド サーバーから直接ステージング環境にデプロイされます。

Builds are deployed to the staging environment directly from the build server.

ソリューションをステージング環境、 DeployToStaging-WhatIf と DeployToStaging にデプロイするために使用されるビルド定義には、次の共通の特性があります:

  • 実際には何もビルドしません。 Rob は、ソリューションをステージング環境にデプロイするときに、テスト環境で確認および検証済みの特定の既存のビルドをデプロイしたいと考えています。 ビルド定義は、配置プロセスを制御するカスタム プロジェクト ファイルを実行するだけで済みます。
  • Rob はビルドをトリガーするときに、ビルド パラメーターを使用して、ビルド サーバーからデプロイするリソースを含むビルドを指定します。
  • ビルド定義は自動的にはトリガーされません。 Rob は、ソリューションをステージング環境にデプロイするときに、ビルドを手動でキューに入れます。

これは、ステージング環境へのデプロイの大まかなプロセスです:

  1. ステージング環境管理者 Rob Walters は、DeployToStaging-WhatIf ビルド定義を使用してビルドをキューに入れます。 Rob は、ビルド定義パラメーターを使用して、デプロイするビルドを指定します。
  2. DeployToStaging-WhatIf ビルド定義は、カスタム プロジェクト ファイルを "what if" モードで実行します。 これにより、Rob がライブ デプロイを実行しているかのようにログ ファイルが生成されますが、実際には宛先環境に変更は加えられません。
  3. Rob はログ ファイルを確認して、ステージング環境に対するデプロイの影響を確認します。 Rob は特に、何が追加され、何が更新され、何が削除されるのかを確認したいと考えています。
  4. Rob は、デプロイが既存のリソースやデータに望ましくない変更を加えないことを確認したら、DeployToStaging ビルド定義を使用してビルドをキューに入れます。
  5. DeployToStaging ビルド定義は、カスタム プロジェクト ファイルを実行します。 これらは、ステージング環境のプライマリ Web サーバーにデプロイ リソースを発行します。
  6. Web ファーム フレームワーク (WFF) コントローラーは、ステージング環境の Web サーバーを同期します。 これにより、サーバー ファーム内のすべての Web サーバーでアプリケーションを使用できるようになります。

配置プロセスのしくみとは?

DeployToStaging ビルド定義は、MSBuild に次の引数を提供します:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;OutputRoot=[path to build folder]

TargetEnvPropsFile プロパティは、インポートする環境固有のプロジェクト ファイルの場所を Publish.proj ファイルに指示します。 OutputRoot プロパティは、組み込みの値をオーバーライドし、デプロイするリソースを含むビルド フォルダーの場所を示します。 Rob はビルドをキューに入れるときに、[パラメーター] タブを使用して OutputRoot プロパティの更新された値を指定します。

When Rob queues the build, he uses the Parameters tab to provide an updated value for the OutputRoot property.

Note

このようなビルド定義を作成する方法の詳細については、「特定のビルドを配置する」を参照してください。

DeployToStaging-WhatIf ビルド定義には、DeployToStaging ビルド定義と同じデプロイ ロジックが含まれています。 ただし、追加の引数 WhatIf=true が含まれています:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;
   OutputRoot=[path to build folder];
   WhatIf=true

Publish.proj ファイル内では、WhatIf プロパティは、すべてのデプロイ リソースを "what if" モードで発行する必要があることを示します。 つまり、デプロイが先に進んだかのようにログ ファイルが生成されますが、実際には宛先環境では何も変更されません。 これにより、実際に変更を加える前に、提案されたデプロイの影響 (特に、追加される内容、更新される内容、削除される内容) を評価できます。

Note

"what if" デプロイを構成する方法の詳細については、「"What If" デプロイの実行」を参照してください。

ステージング環境のプライマリ Web サーバーにアプリケーションをデプロイすると、WFF はサーバー ファーム内のすべてのサーバー間でアプリケーションを自動的に同期します。

Note

Web サーバーを同期するように WFF を構成する方法の詳細については、「Web ファーム フレームワークを使用したサーバー ファームの作成」を参照してください。

運用環境へのデプロイ

ステージング環境でビルドが承認されると、Fabrikam, Inc. チームはアプリケーションを運用環境に発行できます。 運用環境では、アプリケーションが "ライブ" になり、エンド ユーザーのターゲット ユーザーに到達します。

運用環境は、インターネットに接続する境界ネットワーク内にあります。 これは、ビルド サーバーを含む内部ネットワークからは分離されています。 運用環境管理者の Lisa Andrews は、ビルド サーバーから Web 配置パッケージを手動でコピーし、プライマリ運用 Web サーバー上の IIS にインポートする必要があります。

The production environment administrator must manually copy the web deployment packages from the build server and import them into I I S on the primary production web server.

これは、運用環境へのデプロイの大まかなプロセスです:

  1. 開発者チームは、ビルドを運用環境にデプロイする準備ができていることを Lisa にアドバイスします。 チームは、ビルド サーバー上のドロップ フォルダー内の Web 配置パッケージの場所を Lisa にアドバイスします。
  2. Lisa は、ビルド サーバーから Web パッケージを収集し、運用環境のプライマリ Web サーバーにコピーします。
  3. Lisa は IIS マネージャーを使用して、プライマリ Web サーバーに Web パッケージをインポートして発行します。
  4. WFF コントローラーは、運用環境内の Web サーバーを同期します。 これにより、サーバー ファーム内のすべての Web サーバーでアプリケーションを使用できるようになります。

配置プロセスのしくみとは?

IIS マネージャーには、Web パッケージを IIS Web サイトに簡単に発行できるアプリケーション パッケージのインポート ウィザードが含まれています。 この手順を実行する方法のチュートリアルについては、「Web パッケージ の手動インストール」を参照してください。

まとめ

このトピックでは、一般的なエンタープライズ規模の Web アプリケーションのデプロイ ライフサイクルの図を示しました。

このトピックは、Web アプリケーションの展開のさまざまな側面に関するガイダンスを提供する一連のチュートリアルの一部です。 実際には、デプロイ プロセスの各段階で多くの追加のタスクと考慮事項があり、1 つのチュートリアルですべてのタスクをカバーすることはできません。 詳細については、次のチュートリアルを参照してください:

前へ