図 3 は、SharePoint Server プラットフォームでの個々のアセンブリ開発に関して提案された構成の概要を図示しています。開発者のローカル コンピュータ環境は、孤立したワークスペースによって制御されているグループ開発のチーム モデルに準拠しており、信頼できる SharePoint Server インスタンスの開発に役立つ視覚化テクノロジを使用しています。この構成では、開発者は実際に、SharePoint Server 2007 を実行している Microsoft Virtual PC でソリューション開発を実施します。アプリケーション開発時に使用するため、開発者には SharePoint Server 2007 を実行している独自の仮想コンピュータが必要です。

開発環境およびソース コード リポジトリの間の対話は、仮想コンピュータの内部から発生します。この記事の目的では、Microsoft Visual Studio 2005 Team Foundation Server は、開発プロセスに適したソース コントロール製品と考えられますが、概念上は Microsoft Visual SourceSafe と容易に置き換えることができます。

この構成では、総合的なソリューションで作業している他の開発者の作業を妨害したり、侵害したりすることなく、アセンブリの開発、展開、およびテストを実行できるように、開発者に SharePoint Server 2007 サーバーが提供されます。代わりの構成は、1 台の SharePoint Server 2007 仮想コンピュータを維持して、開発者の物理コンピュータ (ゲストの SharePoint Server 2007 仮想コンピュータのホスト) 内でコーディングを実行することです。さらに、開発者は独自の SharePoint Server 2007 仮想コンピュータへ展開することを選択できます。この構成では、SharePoint Server 2007 仮想コンピュータでネットワーク アクセスを維持する必要があります。また、図示されている構成の仮想コンピュータには、Visual Studio Team System Team Client がインストールされており、Team Foundation Server に接続できる必要があります。

開発環境を確立した後に、Team Foundation Server ワークスペースをローカルで作成し、グループ作業による開発で中心のソース コントロールとして Team Foundation Server の使用を開始し、アイテム追跡プラットフォームを動作させることができます。孤立した独自の開発環境の整合性を維持しながら、開発チームがテスト方式の開発にグループでかかわったり、アジャイル Microsoft Solutions Framework 方式を実装したり、SharePoint Server ソリューション向けのアセンブリの共通セットの開発まで進んだりすることができます。この構成により、Team Foundation Server で単一のコード ベースが維持されている間は、独立した生産性を最大限高めることができます。

SharePoint Server のアセンブリ開発モデルは、ビルド環境からのアセンブリ取得で始まり、それらのアセンブリを 1 つのリリース媒体 (Microsoft インストーラまたは SharePoint Server ソリューション) にパッケージングし、各種のビットをテストする統合環境にインストールします。次の図は、リリース マネージャがアセンブリのビルドを取得し、統合環境に移行するプロセスの概要を示しています。

統合環境は、SharePoint Server 構造および分類によって、開発者の環境の構成が理想的にミラーリングされる環境です。リリース マネージャで、アセンブリを共有された統合環境にインストールします。この環境は、統合およびシステムのテストの場所を提供します。この環境では、すべてのアセンブリがテストされ、必要な単体テストに合格するだけでなく、SharePoint Server ソリューションの一部として開発された他のアセンブリと正常に統合され、SharePoint Server 環境内で予想されるとおりに動作することが保証されます。

展開媒体として SharePoint Server の長所となるのは、サーバー ファームにインストールして、他のフロントエンド Web サーバーに自動的に展開できるという事実です。SharePoint Server ソリューションは、[サーバーの管理] を使用して手際よくインストールおよび管理 (アンインストール、非アクティブ化など) されます。ただし、Microsoft インストーラ (.msi) ファイルを利用して、カスタム インストーラ動作を提供し、非常に複雑なインストール要件を指定するウィザードを処理することができます。

図 5 は、開発者の SharePoint Server 2007 環境からのコードの直接的な移行を図示しています。この図では、プル コードに対するビルド サーバーがなく、開発者の SharePoint Server 2007 環境がリリース マネージャのワークステーションであることが前提です。この図は、リリース マネージャがラベルに対してソース コントロールからドキュメントをプルしたことと、手動のビルドおよびパッケージ環境としてローカル コンピュータを使用していることを前提としています。

さらに改良されたプロセス方式のチーム開発環境では、次の図に示されているように、Team Foundation Server を使用して、チェックアウトおよびビルド処理を実行できます。

図 5 のモデルでは、開発者の仮想 MOSS 環境から Team Foundation Server へのアセンブリ コードのチェックインに従い、主要な開発者またはその他のチーム メンバがチェックインをレビューし、プロジェクトをラベリングします。

夜間のビルド (または連続統合) プロセス時に、ソース コードはチェックアウトされ、Team Foundation Server ビルド サーバー機能でコンパイルされ、リリース マネージャが使用できるネットワーク共有でデポジットされます。オプションでは、各ビルド プロセス時に、ビルド サーバーでこのチーム プロジェクト用のビルド サーバー構成時に作成されたテストの指定のセットを実行できます。この時点で、リリース マネージャは、ビルド出力を必要な媒体を使用してパッケージ化し、テスト用の統合環境に展開することを選択できます。

アセンブリ開発と成果物開発との間の大きな違いの 1 つは、SharePoint Server に Web 用の文書および承認された機能の一部としてビルトイン ソース コントロールのための機能があることです。一方、アセンブリ開発は外部のサーバーベースのソース コントロール環境に依存しています。SharePoint Server の機能により、ユーザー グループに表示する前に、コンテンツ承認者がサイトおよび変更点を視覚的に確認できるソース コントロールのような機能が得られます。この機能は、従来のコンテンツ開発と見なされます。

コンテンツ開発が従来の開発と大きく異なることを理解する必要があります。コンテンツ開発に、サイト コンテンツの変更だけでなく、ページ、スタイル、マスタ ページ、およびレイアウトの変更が含まれている限りは、これらの変更を実際に行う場所は生産環境と解釈する必要があります。組織は、ライブ環境内でコンテンツまたは成果物開発を実行する機能を提供するか、コンテンツを生産環境に送信するオーサリング環境を提供するかどうかを指定します。いずれの場合も、コンテンツを開発するハードウェアは生産環境 (つまり、ビジネス ユーザーがコンテンツおよび生産コンテンツ レンダリング環境を開発および展開する生産コンテンツ開発環境) と見なされます。

SharePoint の成果物の場合、これらのアイテムはコンテンツと見なされます。SharePoint Server コンテンツ データベース内に格納され、パブリケーションおよび承認に従います。これらのアイテムはプログラム可能なアセンブリではなく、コンテンツと見なされるので、SharePoint Designer を使用して設計されたアイテムのチーム開発プロセスを観察できます。次の図には、コンテンツまたは成果物とアセンブリ開発との違いの一部が示されています。

図 6 は、SharePoint Server の全体的なソリューション開発の 2 次元プロセスを示しています。仮想アセンブリ開発プロセスは、コンパイルされ、パッケージ化され、開発環境、統合環境、および生産環境の間で展開されるので、コード (チーム開発のプロセスに従って分離された環境で開発されるアセンブリ) の移動によって表されます。水平方向のプロセスは、コンテンツの生産が生産で分類されたハードウェアで行われるようすを示しています。アセンブリ開発が文字通り、指定のサーバー環境の境界 (物理開発、統合、および生産サーバー) 間の環境の移行である場合、コンテンツの開発はより論理的で、単一の生産 SharePoint Server 環境内で行われる可能性もあります。

図 6 では、コンテンツ開発者が SharePoint Designer を使用してマスタ ページを作成し、スタイル シートを変更および作成し、サイト コンテンツを開発し、新しいページも作成しています。これは全コンテンツのオーサリングなので、下書きと最終決定の変更は SharePoint Server Web コンテンツの発行プロセスを通過します。このプロセスは単一の生産環境内で発生する可能性があります。または、図 6 に示すように、承認および発行されたコンテンツおよび SharePoint Designer 成果物は、さらに自動的に 2 つの環境間で作成されたコンテンツ管理パスを経由して表示のみの生産環境に展開することができます。

これらの違いに基づき、次のガイダンスは SharePoint Designer 成果物および他のコンテンツに関してチーム開発を行う組織に役立つ場合があります。

SharePoint Server ソリューションの開発プロセスで、以下が可能なオーサリング環境を確立します。

• コンテンツ開発者は SharePoint Designer を使用して、実際に生産環境を表示するミラー化されたサイト コレクション内でコンテンツ (マスタ ページ、カスタム ページ、スタイルシートなど) を作成および修正できます。

• オーサリング活動では、SharePoint ソース コントロールおよびパブリケーション機能を使用します。

• コンテンツ開発者は、既存の生産環境を修正し、生産 Web ファームに対するコンテンツ管理パスを使用してパブリケーションを実行することができます。

• 生産 Web ファームに展開されるすべてのアセンブリ、Web パーツ、SharePoint Server ソリューション、および構造の変更もオーサリング環境に展開されるように、生産クラス環境がオーサリング環境によって提供されます。

• SharePoint Server Web コンテンツ パブリケーション機能によって提案された変更とコンテンツおよび承認された変更の間のアブストラクションのレベルが与えられるので、オーサリング環境は生産環境内に存在している可能性があります。

• チームの観点から、共有されたオーサリング環境は個々の孤立したオーサリング環境よりも効率的です。

• SharePoint Designer 成果物は、エンタープライズ ソース コントロールと統合する必要はありません。

• エンタープライズ ソース コントロール (Team Foundation Server など) は、厳密にはチーム環境のアセンブリ開発に使用する必要がありますが、コンテンツ管理アイテムをソース コントロールに統合する作業はサポートされているプロセスではありません。

• SharePoint Designer コンテンツ アイテムおよびコンテンツ開発の一部と見なされるアイテムをエンタープライズ ソース コントロールに統合する試行には、手動のプロセスおよび手順に関して広範な方法が必要です。

• SharePoint Designer でコンテンツとしてビルドされるアイテムは、ソース コントロール、承認、およびパブリケーションの Web 用文書のプロセスによって決まります。

コンテンツ管理パスを使用して、生産環境に対する SharePoint Designer の変更を発行します。

コンテンツ管理パスは、オーサリング環境とそれらのコンテンツと同等のものの間で SharePoint Designer で設計されたコンテンツを送信するための最適な主要媒体になります。

SharePoint Designer の .fwp パッケージへのサイト コンテンツのインポートおよびエクスポートで同じ機能が得られる間は、コンテンツ管理パスによって SharePoint Server 環境間でのコンテンツの移行に関して手順が少なく信頼性の高い方法が確実に提供されます。

アセンブリと成果物の開発の大きな違いは、同時のコンテンツ開発を実行している複数の開発者の物理的な調整を行う方法と直接関係があります。複数のコンテンツ開発者に対して単一のオーサリング環境を確立するガイダンスは特に重要です。この考えの根拠になるのは、マスタ ページ、スタイル シート、および他のコンテンツのオブジェクトの移行およびマージに大きな問題がある可能性があることです。これらのオブジェクトはコードではなく、コンテンツと見なされるので、SharePoint Server にはこれらのオブジェクト間でマージを実行する直接的な方法はありません。また、複数のチーム メンバ用に管理および調整するため、複数のオーサリング環境間でこれらのアイテムを移行することは、きわめて困難です。したがって、複数のコンテンツ開発者が SharePoint Designer を使用して、コンテンツを作成および発行できる単一のオーサリング環境により、複数の孤立した環境から 1 つの生産環境にコンテンツ成果物を移行するのに費やす時間が短くなります。

その上、コンテンツ成果物をエンタープライズ ソース コントロールと統合しないという方向性は、アセンブリ開発から大きく逸脱しています。これらのアイテムを SharePoint Designer を通じて SharePoint Server コンテンツ データベースから抽出し、ソース コントロールに含めることによって対応する要件は、手順があまりにも多くなり、エラーが発生しやすくなります。Visual Studio プロジェクトに含めることによってソース コントロールのアイテムを手動でコンパイルすることは、集約的な手順の計画と従うべきルールを必要としますが、SharePoint Designer コンテンツ開発を目的としたデザインタイムが発生することを意味していません。