エンタープライズ Web 配置:シナリオの概要

作成者: Jason Lee

この一連のチュートリアルでは、現実的なレベルの複雑さのサンプル ソリューションを架空のエンタープライズ 展開シナリオと共に使用して、参照実装を提供し、タスクとチュートリアルに共通のコンテキストを提供します。 このトピックでは、チュートリアルのシナリオについて説明し、サンプル ソリューションについて説明します。

シナリオの説明

架空の会社である Fabrikam, Inc.は、リモート営業チームが Web インターフェイスから連絡先情報を格納および取得できるソリューションを作成しています。

Fabrikam, Inc. のアプリケーション ライフサイクル管理 (ALM) プロセスでは、ソフトウェア開発プロセスのさまざまな段階で 3 つのサーバー環境にソリューションをデプロイする必要があります。

• 開発者テストまたは "サンドボックス" 環境。
• イントラネット ベースのステージング環境。
• インターネットに接続された運用環境。

これらの各環境には構成とセキュリティの要件が異なり、それぞれに固有のデプロイの課題があります。

The Fabrikam, Inc. Server Infrastructure

これは、Fabrikam, Inc. の高レベルの開発およびデプロイ インフラストラクチャです。

開発者ワークステーション、ソース管理インフラストラクチャ、開発者テスト環境、ステージング環境はすべて、Fabrikam.net ドメイン内のイントラネット ネットワーク上に存在します。 運用環境は境界ネットワーク (DMZ、非武装地帯、スクリーン サブネットとも呼ばれます) 上に存在し、ファイアウォールによってイントラネット ネットワークから分離されます。 これは一般的な展開シナリオです。通常、ファイアウォールまたはゲートウェイ サーバーを使用して、インターネットに接続する Web サーバーを内部サーバー インフラストラクチャから分離します。

次の点に注意してください。

• 別のビルド サーバーを備えた Team Foundation Server (TFS) 2010 サーバーは、ソース管理と継続的インテグレーション (CI) 機能を提供します。
• 開発者テスト環境には、インターネット インフォメーション サービス (IIS) 7.5 Web サーバーと、SQL Server 2008 R2 データベース サーバーが含まれています。
• 運用環境には、Web ファーム フレームワーク (WFF) コントローラー サーバーによって同期された複数の IIS 7.5 Web サーバーと、SQL Server 2008 R2 データベース サーバーが含まれます。 実際には、データベース サーバーはクラスタリングまたはミラーリングを使用して、スケーラビリティと可用性を向上させることができます。
• ステージング環境は、運用環境の構成を可能な限り密接にレプリケートするように設計されています。
• ファイアウォールとネットワーク分離ポリシーでは、イントラネットから境界ネットワークへの直接の自動展開は許可されません。

これらの各環境の構成については、2 番目のチュートリアル「 Web 配置用のサーバー環境の構成」で詳しく説明されています。

ALM のチーム ロール

これらのユーザーは、Contact Manager ソリューションの作成、管理、構築、および発行に関与しています。

• Matt Hink は Fabrikam, Inc. の Web アプリケーション開発者です。彼は、Visual Studio 2010 を使用して Contact Manager ソリューションを開発したチームの一員です。 Matt は開発者テスト環境のサーバーに対する完全な管理者権限を持っています。これにより、ニーズを満たすように環境を構成できます。 また、Visual Studio 2010 TFS インスタンスへのユーザー アクセス権を持ち、そこで Contact Manager ソリューションのソース コードを格納します。

• Rob Walters は、Fabrikam, Inc. 開発チームのサーバー管理者です。 Rob は TFS サーバーに対する管理アクセス権を持っているので、TFS とチーム ビルドのすべての側面を構成できます。 Rob は、テストおよびステージング Web サーバーへの管理アクセス権も持ち、テスト環境とステージング環境のデータベース サーバーのデータベース管理者 (DBA) として機能します。 Rob は、次のタスクを実行するように TFS サーバーで Team Build を構成しました。

  • ユーザーがファイルを TFS にチェックインするたびに、アプリケーションで単体テストをビルドして実行します。 これは CI と呼ばれます。
  • アプリケーションが単体テストに合格したら、Contact Manager アプリケーションをテスト環境に自動的に展開します。 これには、初期デプロイ時のテスト サーバーへのデータベースの発行と、初期デプロイ後のデータベースへの更新が含まれます。
  • シングルステップ プロセスで、Contact Manager アプリケーションをステージング環境に展開します。
  • Web サーバー管理者と DBA がアプリケーションを運用環境に発行するために使用できる Web パッケージを作成します。

• Lisa Andrews は、Fabrikam, Inc. 運用サーバーへのアプリケーションの展開を担当するサーバー管理者です。 彼女は、TFS チーム ビルドが Contact Manager アプリケーションをビルドした後に Web 展開パッケージを格納する共有への読み取りアクセス権を持っています。 また、運用 Web サーバーへの管理アクセス権を持っているので、アプリケーションを運用環境に展開できます。 さらに、データベースとデータベースの更新を運用環境のデータベース サーバーにデプロイする DBA として機能します。

連絡先マネージャー ソリューション

Contact Manager ソリューションは、登録済みのログイン ユーザーが Web インターフェイスを介して連絡先情報を追加および編集できるように設計されています。 Contact Manager ソリューションは、次の 4 つの個別のプロジェクトで構成されます。

• ContactManager.Mvc。 これは、ソリューションのエントリ ポイントを表す MVC3 Web アプリケーション プロジェクト ASP.NET です。 ユーザーに連絡先の詳細を作成して表示する機能を提供するなど、いくつかの基本的な Web アプリケーション機能が提供されます。 アプリケーションは、Windows Communication Foundation (WCF) サービスを使用して連絡先を管理し、ASP.NET アプリケーション サービス データベースを使用して認証と承認を管理します。
• ContactManager.Database。 これは Visual Studio 2010 データベース プロジェクトです。 プロジェクトでは、連絡先の詳細を格納するデータベースのスキーマを定義します。
• ContactManager.Service。 これは WCF Web サービス プロジェクトです。 WCF は、呼び出し元が Contact Manager データベースに対して作成、取得、更新、削除 (CRUD) 操作を実行できるようにするエンドポイントを公開します。 このサービスは、Contact Manager データベースとContactManager.Common.dll アセンブリに依存しています。
• ContactManager.Common。 これはクラス ライブラリ プロジェクトです。 WCF サービスは、このアセンブリで定義されている型に依存します。

ソリューションとそのデプロイ要件の完全なレビューは、このシリーズの最初のチュートリアルである 「エンタープライズでの Web 配置」で提供されています。

配置タスク

大規模なorganization内の異なる環境にアプリケーションをデプロイするには、いくつかの異なるタスクが関係します。 チュートリアルで取り上げる主なタスクは次のとおりです。

このドキュメントで前述したユーザーの観点から、デプロイ プロセスの各ステップの一覧を次に示します。

1. チームのすべてのメンバーは、Visual Studio 2010 の Contact Manager ソリューションを確認して、主要な展開要件と問題を判断します。
2. Matt Hink は、Contact Manager ソリューションを開発者ワークステーションから開発者テスト環境に直接デプロイして、デプロイ ロジックの初期テストを行う場合があります。
3. Matt Hink は、TFS のソース管理にアプリケーションを追加します。
4. Rob Walters は、Team Build で Contact Manager ソリューションのさまざまなビルド定義を作成します。 1 つのビルド定義では、ユーザーが新しいコードをチェックインするたびに、CI を使用してソリューションを開発者テスト環境にデプロイします。 別のビルド定義を使用すると、ユーザーは必要に応じてステージング環境へのデプロイをトリガーできます。
5. ユーザーが新しいコードをチェックインするたびに、Team Build によってソリューション コンポーネントが自動的にビルドされ、単体テストが実行され、ビルドが成功し、単体テストに合格した場合に、ソリューションが開発者テスト環境にデプロイされます。
6. ユーザーがステージング環境へのデプロイをトリガーすると、ソリューションはパッケージ化され、シングルステップ プロセスでデプロイされます。 このプロセスでは、運用環境への手動デプロイ用のパッケージも生成されます。
7. Lisa Andrews は、手順 6 で作成した Web パッケージを手動でインポートすることで、アプリケーションを運用環境にデプロイします。

デプロイに関する主な問題

Contact Manager ソリューションと Fabrikam, Inc. のシナリオでは、複雑なエンタープライズ規模のソリューションをデプロイするときに発生する可能性のあるさまざまな一般的な問題と課題が強調されています。 次に例を示します。

• 開発者またはテスト環境、ステージング プラットフォーム、運用サーバーなど、複数の環境にプロジェクトをデプロイできる必要があります。 ソリューションは、環境ごとに異なる構成設定でデプロイする必要があります。
• 1 つのステップまたは自動化されたビルドと配置プロセスの一環として、複数の依存プロジェクトを同時にデプロイする必要があります。
• 自動プロセスからデプロイを推進できる必要があります。 たとえば、CI プロセスを使用して、新しいコードがチェックインされたときに Web アプリケーションをステージング環境にデプロイしたいとします。
• 開発者がターゲット環境ごとに正しい構成設定や必要な資格情報を持つ可能性は低く、Visual Studio の外部からデプロイ プロセスを制御し、デプロイ変数を設定できる必要があります。
• スキーマ ベースのデータベース プロジェクトをデプロイし、後続のデプロイで既存のデータを保持する必要があります。
• ユーザー アカウント データをデプロイせずに、メンバーシップ データベースをアドホックにデプロイする必要があります。 また、既存のユーザー アカウント データを失うことなく、デプロイされたメンバーシップ データベースのスキーマを更新する必要がある場合もあります。
• コンテンツをさまざまなターゲット環境に展開する場合は、特定のファイルまたはフォルダーを除外する必要があります。

さらに、更新プログラムが頻繁に実行され、増分的にデプロイを管理すると、いくつかの追加の課題がスローされます。 次に例を示します。

• 開発者が新しいコードをチェックインするたびに単体テストを実行します。 コードが単体テストに合格した場合にのみ、ソリューションをデプロイする必要があります。
• Web アプリケーションをステージング環境または運用環境にデプロイする場合は、展開プロセスの間、ユーザーを app_offline.htm ファイルにリダイレクトする必要があります。
• デプロイ アクティビティをログに記録する必要があります。 展開プロセスでは、指定された受信者に、成功または失敗したデプロイの電子メール通知を送信する必要があります。
• 自動デプロイが失敗した場合は、デプロイ プロセスで現在のデプロイを再試行するか、代わりに前の Web パッケージをデプロイする必要があります。

前へ次へ