アセンブリ開発と成果物開発との間の大きな違いの 1 つは、SharePoint Server に Web 用の文書および承認された機能の一部としてビルトイン ソース コントロールのための機能があることです。一方、アセンブリ開発は外部のサーバーベースのソース コントロール環境に依存しています。SharePoint Server の機能により、ユーザー グループに表示する前に、コンテンツ承認者がサイトおよび変更点を視覚的に確認できるソース コントロールのような機能が得られます。この機能は、従来のコンテンツ開発と見なされます。
コンテンツ開発が従来の開発と大きく異なることを理解する必要があります。コンテンツ開発に、サイト コンテンツの変更だけでなく、ページ、スタイル、マスタ ページ、およびレイアウトの変更が含まれている限りは、これらの変更を実際に行う場所は生産環境と解釈する必要があります。組織は、ライブ環境内でコンテンツまたは成果物開発を実行する機能を提供するか、コンテンツを生産環境に送信するオーサリング環境を提供するかどうかを指定します。いずれの場合も、コンテンツを開発するハードウェアは生産環境 (つまり、ビジネス ユーザーがコンテンツおよび生産コンテンツ レンダリング環境を開発および展開する生産コンテンツ開発環境) と見なされます。
SharePoint の成果物の場合、これらのアイテムはコンテンツと見なされます。SharePoint Server コンテンツ データベース内に格納され、パブリケーションおよび承認に従います。これらのアイテムはプログラム可能なアセンブリではなく、コンテンツと見なされるので、SharePoint Designer を使用して設計されたアイテムのチーム開発プロセスを観察できます。次の図には、コンテンツまたは成果物とアセンブリ開発との違いの一部が示されています。
図 6. アセンブリと成果物開発プロセスの違い
.gif)
図 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 コンテンツ開発を目的としたデザインタイムが発生することを意味していません。