次の方法で共有

エンタープライズ Web 展開シナリオ概要

  • [アーティクル]

作成者: Jason Lee

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

シナリオの説明

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

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

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

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

Fabrikam, Inc.サーバー インフラストラクチャ

これは、Fabrikam, Inc. の高度な開発および展開インフラストラクチャです。

The high-level development and deployment infrastructure at 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 サーバーで次のタスクを実行するようにチーム ビルドを構成しました。

    • ユーザーがファイルを 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 つの個々のプロジェクトで構成されます。

The Contact Manager solution is designed to let registered, logged-in users add and edit contact information through a web interface.

  • ContactManager.Mvc。 これは、ソリューションのエントリ ポイントを表す ASP.NET MVC3 Web アプリケーション プロジェクトです。 ユーザーに連絡先の詳細を作成および表示する機能を提供するなどの基本的な 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 配置」で提供されます。

配置タスク

大規模な組織のさまざまな環境へのアプリケーションの展開には、いくつかの異なるタスクが関係します。 チュートリアルで取り上げる主なタスクは次のとおりです。

There are several distinct tasks involved in deploying applications to different environments in a large organization.

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

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

展開に関する主な問題

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

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

さらに、更新プログラムが頻繁かつ段階的に発生する場合、展開の管理には、いくつかの追加の課題が発生します。 次に例を示します。

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

前へ次へ