SharePoint アプリケーション ライフサイクル管理
SharePoint テクノロジを使用して、アプリケーション開発に共通のアプリケーション ライフサイクル管理 (ALM) の概念およびプラクティスを適用します。
提供元: Eric Charran、Microsoft Corporation
共同作成者: Vesa Juvonen、Microsoft Corporation | Steve Peschka、Microsoft Corporation
重要： このトピックは、自動的にホストされる SharePoint アドインについて取り上げます。自動的にホストされるアプリのプレビュー プログラムは終了しました。 自動的にホストされる SharePoint アドインに対するすべての参照を無視してください。
アプリケーション ライフサイクル管理 (ALM) の概要
Microsoft SharePoint はオンプレミスと、ホストまたはパブリック クラウドの両方のプラットフォームに向けた SharePoint テクノロジに基づいたアプリケーションを作成、展開するためのいくつかの選択肢を開発者に提供します。 SharePoint はさまざまな形のアプリケーション構築を可能とするさらなる柔軟性、ならびに標準ベーステクノロジをアプリケーションで使用するための新たな選択肢を提供します。 SharePoint の新しいアプリケーション モデルがもたらす機能と展開の選択肢は開発者にとって新しい没入型のアプリケーションを作成するための効果的な手段となりますが、開発者は開発プロセスに、品質、テスト、および ALM の注意点を導入できなければなりません。 この記事では SharePoint テクノロジを使用した、一般的な ALM の概念およびプラクティスをアプリケーション開発に適用します。
新機能
SharePoint は、アプリケーション実装の新しいパラダイムを確立します。 この SharePoint テクノロジを使ったアプリケーション開発の変化により、開発者と設計者はアプリケーション開発の新しいパターン、プラクティス、展開モデルを十分に理解する必要があります。 Sharepoint を使ったソリューション開発のアプリケーション モデルが変わっても、ソリューション開発で使用されてきたパターンの多くは、テクノロジの選択、実装技術を含む既存の web アプリケーション開発テクノロジと矛盾するものではありません。
次のリソースは、SharePoint テクノロジを使用して構築することができるアプリケーションの種類を説明したものです。オンプレミス、クラウド アプリケーションの両方を考慮したものになっています。 SharePoint アドインのホスティング オプションについては、「 SharePoint アドインを開発およびホストするためのパターンを選択する」を参照してください。
また、幅広いソリューションの実装の選択肢があるため、Microsoft では、SharePoint を使用してアプリケーションを開発する際には、使用するテクノロジを十分評価することをお勧めします。 アプリケーションの作成では、プレゼンテーションとユーザーエクスペリエンスのレイヤーに HTML5 や JavaScript などの標準ベースのテクノロジの活用を、そして、SharePoint を含むバックエンド.サービスへのサービスベースのアクセスには OData と OAuth を活用できます。 完全信頼コード (SharePoint に配置するコンパイル済みのアセンブリ) が必要かどうかを慎重に検討する必要があります。 その開発パラダイムは特定の状況では依然として有効で必要なものですが、それは ALM プロセスには相当な負担を強いることにつながります。
SharePoint 上のアプリケーション用の新しい柔軟な開発テクノロジの詳細については、「 SharePoint 開発の概要」を参照してください。
メリットと変更
SharePoint はさまざまな言語やプログラミング アーキテクチャを含むアプリケーション開発テクノロジに柔軟に対応しているため、開発者はメインストリームの加発技術をめぐる既存の ALM プラクティスを SharePoint への内蔵のために適応させる必要があります。 SharePoint アプリケーションとしての SharePoint への配置を含めるよう、テスト、ビルド確立、展開、品質管理などの概念を拡張することができます。 これは、多くの開発者が、SharePoint のコア機能を拡張するサーバーサイドのファームソリューションの作成と展開に慣れている一方で、SharePoint アプリケーションのより容易となった、柔軟性ある新しい開発モデルにおける共通の AML プラクティスを実装プロセスに採用する必要があることを意味します。
顧客がクラウド ホスト型の SharePoint の実装へと移行し続けるに伴い、開発者は、組織の物理境界の外部にある開発、テスト、展開の対象環境を取り込むために ALM 概念の拡張方法を理解する必要が出てきます。 これには、アプリケーションの開発、テスト、展開を行うためのテクノロジ戦略の評価作業が含まれます。
開発者も、設計者も、さまざまな種類のホスティング オプションを網羅し、組み合わせた複数のアプリケーション コンポーネントにより構成されるソリューションの作成に精通することになります。 この適応プロセスの間は、一方的に ALM の手順をこれらのアプリケーションに適用する必要があります。 たとえば、品質の確認や、前のビルド以降の回帰の有無を確認するテストと並行してオンプレミス サービスに基づくアプリケーション (IIS、ASP.NET、MVC、WebAPI、WCF)、Microsoft Azure、SharePoint、SQL Azure の展開が必要となることがあります。 これらの要件は、オンプレミスまたはサーバー側ソリューションでよく知られている手順である、毎日のビルドと展開、配置のプロセスの考え方に相当な変化をもたらします。
開発チームに関する考慮事項
複数のアプリケーション開発者や設計者からなる組織では、最高品質のアプリケーションを製作し、十分な開発生産性を確保するため、SharePoint のチーム開発を慎重に計画する必要があります。 アプリケーションの開発手法がより柔軟になったため、アプリケーションのビルドのプロセスに高品質のコードを供給するには ALM のプラクティスやパターンだけでなく、コードの書き方までを明確にすることが必要です。
これらの注意点は、適当な開発環境を選択するところから始まります。 従来の開発は、Visual Studio TFS 2012 のようにビルド、展開、およびテスト機能を提供する共通のコード リポジトリに接続された仮想マシンにおいて個別の開発を行うことでした。 TFS は、現在でも ALM 戦略の強力なインストルメンタル コンポーネントであり開発作業の中心ですが、各チームは各種の開発環境オプションにわたって TFS の使用方法を検討する必要があります。
対象環境、ソリューションの種類 (どのコンポーネントがオンプレミスに、どのコンポーネントがクラウド インフラストラクチャまたはサービスにホストされるか) に応じて、開発者は新しい開発環境オプションの組み合わせから選択できるようになりました。 これらのオプションは、SharePoint 開発者サイト テンプレート、Office 365 開発者テナントなどの新しい選択肢、および Windows 8 または Windows Server 2012 の Hyper-V を使用する仮想マシンベースの開発などのレガシの選択肢からなります。
次のセクションでは、アプリケーション開発者および開発チームのために開発環境の注意点を説明します。
開発環境の注意点
開発環境の選択は、さまざまな要因に基づいて決定します。 これらの注意点は、開発するアプリケーションの種類やアプリケーションの対象プラットフォームによって大きな影響を受けます。 従来は、SharePoint Server 2010 用にアプリケーションを作成する場合、開発者は仮想マシンを準備して他とは隔離した状態で開発を行いました。 これは、完全に信頼されるソリューションの展開には、IIS などのコア SharePoint の依存関係のリスタートが必要とされていたという事実によるものであり、複数の開発者が単一の SharePoint 環境を使用することを防いでいます。 開発テクノロジが変化して、開発者の開発用アプリケーションのオプションも増えたため、開発者およびチームは自分たちが利用できる開発環境の選択肢を理解する必要があります。 図 1 に開発環境とツールの組み合わせを示し、さらに対象環境に展開できるソリューションの種類も示します。
図 1. 開発環境のコンポーネントとツール
[
開発環境の考え方
SharePoint を使用したアプリケーションの設計、実装の方法に対する投資の結果、サーバー側コードを使う手法による開発が本当に必要かどうかを検討する必要が生じています。 開発者はクラウドにホストされたアプリケーションを作成でき、特に SharePoint については、仮想環境に依存する開発を進める必要は少なくなっています。 既存のクラウドベース (パブリック クラウド、プライベート クラウドを問わず) のインフラを使用し、リモート開発モデルによってソリューションを構築するべきです。 仮想環境を作成し、調整することなく、手早く簡単に開発環境を用意できれば、開発者はインフラ管理ではなく、生産と品質により多くの時間を投入することができます。
仮想化された SharePoint のインスタンスを選ぶか、または新しい SharePoint 開発サイトテンプレートを採用するかは、アプリケーションを SharePoint に配置し、実行するのに完全信頼コードを必要とするかどうかによります。 完全信頼コードが不要であれば、開発者向けサイトテンプレートの使用をお勧めします。このテンプレートは Office 365 開発テナント、またはオンプレミスの SharePoint の実装の中から取得できます。 開発者向けのサイト テンプレートは、Visual Studio から開発者がアプリケーションを直接 SharePoint に配置できるよう設計されています。 Office 365 の開発者向けサイトは、アプリケーションの分離と OAuth に適した設定になっているため、ここでアプリケーションの作成とテストをすぐに始めることができます。
次のセクションでは、アプリケーション構築のさまざまな環境の選択肢について詳しく説明します。
O365 開発サイト (パブリック クラウド)
図 2 は、開発者が Office 365 を開発環境として使用する方法、および Office 365 でホストできる SharePoint アプリケーションを作成する各種のツールを含める方法を示します。
図 2. Office 365 のアプリケーション開発
[
MSDN サブスクリプションを持つ開発者は、SharePoint 開発者サイトを含む開発テナントを取得できます。 SharePoint開発者向けサイト は、アプリケーションの開発用に事前構成されています。 ユーザーは、アプリケーションの開発に Visual Studio 2012 を使用できるだけでなく、Office 365 の開発サイトの利用により、アプリケーションを構築するサイト内で Napa を使用することができます。 Office 365開発者サイトの概要の詳細については、「Office 365での SharePoint アドインの開発環境のセットアップ」を参照してください。
手始めに、Office 365 にホストするプロバイダー ホスト型のアプリケーション、オンプレミスまたは他のインフラにホストするプロバイダー ホスト型のアプリケーションを作成できます。 この環境の利点は、SharePoint 開発環境のための仮想化やホスティングに関して考慮しなければならないさまざまな問題を Office 365 によって抽象化できることです。 この種の開発環境で検討すべき最も重要な点は、Share Point に展開するときに完全信頼コードを必要とするアプリケーションに対応できないことです。 Microsoft は、可能な限り SharePoint クライアント側オブジェクト モデル (CSOM) と、JavaScript など、クライアント側のテクノロジを使用することをお勧めします。 完全信頼コードが必要 (で、SharePoint で実行するコードの展開は不要) な場合、サーバー側コードは自動ホスト型の展開または、プロバイダー ホスト型の展開で配置することをお勧めします。 プロバイダー ホスト型のインフラストラクチャに配置した完全信頼コードによるソリューションも CSOM を使用しますが、C# などの言語を使用できます。 プロバイダー ホスト型のモデルで配置されたアプリケーションは、スタックなど、他のテクノロジを使用していることがありますが、それでも SharePoint とのやりとりを CSOM で行うことができる点に注意してください。
より大きなソリューションを含む個別の機能またはアプリケーションを作成する開発チームは、統合テスト コンポーネントへの集中展開対象を必要とします。 各開発者は、独自の Office 365 開発者サイト上で機能またはアプリケーションを作成するため、各開発者のアプリケーションのコンポーネントがそこに展開されるように、対象テナントまたはオンプレミス環境内に集中サイト コレクションを用意する必要があります。 このアプローチでは、ソリューション コンポーネント間での統合テストを集中して実施する場所を提供します。 「この文書のテストのセクション」 では、このプロセスを詳しく再検討します。
開発サイト (リモート開発)
SharePoint アプリケーション開発の主要な手段としてOffice 365開発者サイトを使用しないことを選択した組織または開発者は、オンプレミスの開発者サイトを使用して SharePoint アプリケーションを開発できます。 このモデルでは、Office 365開発者サイトの機能は、SharePoint ファーム内でホストされているオンプレミスの開発者サイトに置き換えられます。 お客様は、開発者サイト インスタンスを収容するために SharePoint ファームをデプロイすることで、開発用プライベート クラウドを作成できます。 お客様は、開発者サイト テンプレートの作成を提供したり、SharePoint 製品内機能を使用して開発者サイト インスタンスをプロビジョニングしたりするために、独自のガバナンス自動化を提供できます。 図 3 は、この設定を示しています。
図 3. 開発者サイト テンプレートを使用したオンプレミス アプリケーション開発
[
図 3 では、オンプレミスの SharePoint ファームをホストとして使用するときに開発者サイトで有効にできる開発ツールとアプリケーションの種類について説明します。 NapaOffice 365 開発ツールは、Office 365開発サイトにのみ存在する機能であるため、この環境では使用できないことに注意してください。
開発者サイト インスタンスをホストするSharePoint ファームを監視し、サービスと復旧ポイントと時間レベルの目標を満たす必要があります。これにより、アプリケーションの作成に依存する開発者は生産性を高め、停止を経験することはできません。 お客様は、弾力性やスケール ユニット、管理ファブリックなどのプライベート クラウドの概念をこの環境に適用できます。 運用と管理は、開発者サイトもホストされている SharePoint ファームに適用する必要があります。 これにより、古い、または使用されていない複数の開発者サイトの監視されていないスプロールを制御し、環境をスケーリングする必要があるタイミングを理解する方法が提供されます。
顧客は、開発者サイトを収容しホストする SharePoint ファームをホストするために Microsoft Azure のようなサービスとしてのインフラストラクチャ (IaaS) 機能の使用、または独自に保有するオンプレミスの仮想または物理環境の使用を決定することができます。 このモデルの使用のために、SharePoint を開発者ごとにインストールする必要はないことに注意してください。 リモートのアプリケーション開発に必要なのは、Visual Studio および開発ワークステーション上の Office および SharePoint の開発ツールだけです。
開発者は、プロバイダー向けのホスト型アプリケーションを展開するためにプロバイダー ホスト型インフラストラクチャを構築する必要があります。 SharePoint アプリケーションのプロバイダー ホスト型コンポーネントは、幅広いテクノロジで実装可能ですが、SharePoint の外部で動作するアプリケーションのコンポーネントをホストするためのインフラストラクチャを提供する必要があります。 たとえば、チームが SharePoint アプリケーションを開発していて、そのユーザー エクスペリエンスおよび他のコンポーネントが ASP.NET アプリケーションに属する場合は、その開発チームはローカル バージョンの IIS、SQL Server、その他 ASP.NET の従来型の ALM チーム開発パターンなどを使用する必要があります。
内蔵のファーム環境 (仮想化ファーム開発)
SharePoint ファームでの実行に完全信頼コードの配置を必要とするソリューションには、(多くの場合仮想化された) 完全な SharePoint の実装が必要です。 SharePoint 用のオンプレミス開発環境を作成する方法のガイダンスについては、「 SharePoint アドインのオンプレミス開発環境を設定する」を参照してください。
図 4 は、オンプレミスの仮想化された環境を使用して作成できるアプリケーションの種類を示します。
図 4. 仮想化環境によるオンプレミス開発
[
開発者は、独自の SharePoint ファーム内の SharePoint およびクラウド ホスト型のアプリケーションの開発、および完全な信頼の ファーム ソリューション の開発をリモートで行うことができます。 これらのファームは、開発者のワークステーションか集中仮想化プライベート クラウドの上で動作する、開発者がアクセスしやすい仮想化サーバー内にホストされていることが多くなっています。 通常、SharePoint ファームの環境は、他の開発者のファームとは独立させることにより、重要なサービス (IIS を指す) の再起動が必要となる場合がある完全な信頼コードの開発に必要な隔離レベルを提供します。
リモート開発は、内蔵ファームの内部や完全な信頼コードの開発で行えます。それは各開発ファームが分離されて単一の開発者専用となっているためです。
組織または開発者は、仮想コンピュータで動作している SharePoint ファームの管理および更新を行います。 単一のアプリケーションについて作業をしている開発者の場合、複数の仮想コンピュータで動作している開発ファーム全体にわたってパリティを維持する必要があります。 このプラクティスによって、アプリケーション用に開発されたコードの各コンポーネントに一貫性があることが保証されます。 その他の共通の注意点は、ドメイン アクセスおよび資格情報、サービス アプリケーション資格情報、テスト ID またはアカウント、およびその他の環境についての構成要素 (証明書など) など、ファームの標準的な構成です。
開発サイトの集中化ファームと同じく、開発者の SharePoint ファームが動作するこれらの仮想マシンは、Microsoft Azure などの laaS プラットフォームおよびオンプレミスのプライベート クラウドにホストすることができます。
仮想マシンでは、他の開発用仮想マシンから相当に隔離し独立させることができますが、チームでは各仮想マシンの構成の間に均一性を持たせることに苦労しています。 これには、共通ドメイン、アカウントおよびセキュリティ、SharePoint 構成および Visual Studio Team Foundation Server (TFS) などのソース管理リポジトリへの接続を含みます。
ALM 設計の注意点
SharePoint アプリケーションを構築する場合、一貫性と品質のために、ガバナンスおよび共通の開発プラクティスを提供する上で順守すべきいくつかの注意点があります。 ALM 原則を SharePoint アプリケーション開発に適用する場合、開発者はプロセス上の注意点と同じく技術上の注意点にも集中する必要があります。
Visual Studio Team Foundation Server 2012 などの ALM プラットフォームのサポートは、通常、特に同じ一連のプロジェクトに取り組む開発者のチームでアプリケーション開発を行う場合の要件です。 SharePoint アプリケーションは、他の技術ソリューションと同様に、コード リポジトリの管理とバージョン管理、サービスの構築、サービスのテスト、リリース管理のプラクティスを必要とします。 次のセクションでは、SharePoint アプリケーションのさまざまなアプリケーション モデルに適用される ALM に関する考慮事項について説明します。
概要
各種の SharePoint アプリケーションでは、ALM の注意点を一律のコンセプトで適用する必要があります。 ただし、ビルド、テスト、および変化の管理についてのプラクティスと手順は調整する必要があります。
一部の SharePoint アプリケーションでは、クライアント側テクノロジを使用します。 SharePoint Server 2010 アプリケーションの開発経験のある開発者の多くは、ALM 原則を開発してコンパイルされていないコードに適用する作業を調整しなければなりません。 この調整作業には、コンパイルされたコードを含まないソリューションに、「ビルド」などのコンセプトを適用することが含まれます。 Visual Studio 2012 などの ALM プラットフォームでは、第一にコードをコンパイルして、第二に、ビルドに対してビルド検証テスト (BVT) を動作することで、ビルドを検証する機能を内蔵しています。
SharePoint アプリケーションの場合、ビルドとテストに関連するプロセスは、従来のアプリケーション開発プロセスと一致している必要があります。 これには、ソリューションをコンパイルしてターゲット環境にデプロイする ALM プラットフォームによるビルド スケジュールの作成が含まれます。
ビルド プロセス
SharePoint アプリケーションのビルド プロセスは、ALM プラットフォームによって容易になります。 Visual Studio Team Foundation Server 2012 は、Visual Studio 2012 (統合の継続) からのソリューションの確認または指定したスケジュール間隔によってトリガーできるビルドおよびテストサービスの両方を提供します。
SharePoint ビルド コンポーネント
SharePoint アプリケーション開発のビルド プロセスを計画する場合、図 5 に示すように、開発者はコンポーネント間の相互作用を考慮する必要があります。
図 5. SharePoint ホスト型のアプリケーション ビルド コンポーネント
図 5 のイラストは、SharePoint アプリケーションの論理表記です。 このイラストは、SharePoint ホスト型アドイン を示し、Visual Studio 2012SharePoint ホスト型アドイン プロジェクトの一部である重要なアプリケーション オブジェクトを強調表示します。 SharePoint アプリケーション プロジェクトは、SharePoint に登録される機能、パッケージ、およびマニフェストを含みます。 このプロジェクトはさらに、ページ、スクリプト ライブラリ、およびその他の SharePoint アプリケーションを構成するユーザー エクスペリエンスの要素を含みます。 さらに SharePoint プロジェクトは、対象の SharePoint 環境への展開に必要な証明書を含む関連ファイルを備えています。
図 6. プロバイダー向けのホスト型および自動ホスト型のアプリケーション ビルド コンポーネント
図 6 は、SharePoint クラウド ホスト型アプリケーション (自動ホスト型またはプロバイダー ホスト型)を示します。 プロジェクト構造の主な違いは、Visual Studio 2012 ソリューションでは、クラウド ホスト型のアプリケーション コンポーネントを含む 1 つ以上のプロジェクトに加えて SharePoint アプリケーション プロジェクトを含むことです。 これらが含むのは、Web アプリケーション、SQL データベース プロジェクト、または Azure に展開されるサービス アプリケーションまたはオンプレミスのプロバイダー ホスト型インフラストラクチャ (ASP.NET など) およびその他のソリューション コンポーネントです。 高信頼アプリケーションを使用したパッケージ化と展開のガイダンスについては、「高 信頼 SharePoint アドインのパッケージ化と発行」を参照してください。
図 7. ALM と Visual Studio Team Foundation Server
図 7 は、ALM プラットフォームとしての TFS を示しています。 Teams では、TFS を使用してコードを格納し、オンプレミスにデプロイされた TFS を使用するか、Microsoft クラウドベースの TFS サービスを使用してチーム開発を行います。 TFS は、ビルド定義を介して SharePoint アプリケーションでビルドと展開アクティビティを実行するように構成できます。 TFS を使用して、ビルド定義の一部であるコード化された UI テストの実行によって自動化されるビルド検証テスト (BVT) を実行することもできます。
図 8. TFS ビルド対象
図 8 は、TFS ビルド定義によって実行されるスクリプトが SharePoint アプリケーション コンポーネントを展開する対象環境を示します。 SharePoint ホスト型アプリケーションの場合は、SharePoint Online または オンプレミスの SharePoint アプリケーション カタログに向けた展開を含みます。
クラウド ホスト型の SharePoint アプリケーションの場合は、SharePoint の外部にある追加のインフラストラクチャを必要とするソリューションのコンポーネントが対象環境に展開されています。 自動ホスト型のアプリケーションの場合は Microsoft Azure です。 プロバイダー向けのホスト型アプリケーションの場合、このインフラストラクチャは Microsoft Azure または他のオンプレミスまたは IaaS ホスト型環境です。
SharePoint アプリケーション向けのビルドの作成
TFS が提供するビルド サービスは、対象の環境に自動化された方法で、ソース管理に登録されたソリューションをコンパイルし、展開用の集中ドロップ ロケーションに出力を配置することができます。 TFS が SharePoint アプリケーションの自動化ビルド、展開、テストを実施するように構成する主なメソッドでは、Visual Studio にビルド定義を作成します。 このビルド定義は、どのコード プロジェクトをコンパイルするかや、コンパイル後の作業 (テストや対象環境への実際の展開など) についての情報を含みます。 Team Foundation Build Service の詳細については、「Team Foundation Build Service の セットアップ」を参照してください。
連続的にインテグレーションを行う場合は、開発者がコードをチェックインするときにビルド定義をトリガーすることができます。 さらにビルド定義は、設定した間隔で実行するようにスケジュールすることも可能です。
SharePoint アプリケーションの場合、開発者は Office/SharePoint 継続的インテグレーションと TFS 2012 ビルド定義プロジェクトを使用して、スケジュールされたビルドまたは継続的インテグレーションを実現する必要があります。 このプロジェクトは、ビルド定義と Windows PowerShell スクリプトに加え、継続的インテグレーション モデルで Visual Studio Team Services またはオンプレミス バージョンの TFS を構成して SharePoint アプリケーションをビルドおよび展開する方法を説明するプロセス手順を提供します。 開発者は、このプロジェクトに含まれるコンポーネントをダウンロードして、適切な TFS のインスタンスを構成する必要があります。 SharePoint アプリケーション用に提供されるビルド定義を使用して TFS を構成する方法、および Windows PowerShell スクリプトを使用して SharePoint アプリケーションをターゲット環境に展開するようにビルド定義を構成する方法については、Office/SharePoint Continuous Integration with TFS 2012 のドキュメントを参照してください。
ビルドおよび展開プロシージャの構成
図 9 は、ビルド定義の作成、構成、および展開がチームの TFS インスタンスに実行済みの場合の SharePoint アプリケーションのビルドおよび展開の標準プロセスを示します。
図 9. TFS のビルドおよび展開プロセス
[
開発者は、SharePoint アプリケーション Visual Studio 2012 ソリューションをチェックインします。 目的の構成 (連続的インテグレーションまたはスケジュール済みビルド) によって、TFS ビルド サービスは SharePoint アプリケーション ビルド定義で定義されるステップを実行します。 開発者が構成するこの定義には、連続的インテグレーション ビルド プロセス テンプレートおよびビルド後に実行する指示が含まれ、アプリケーション展開用の Windows PowerShell スクリプトを実行します。 SharePoint Online にアプリケーションを展開するには、SharePoint Online Management Shell 拡張が必要となることに注意してください。 SharePoint Online 管理シェル拡張機能の詳細については、ダウンロード センターの 「SharePoint Online 管理シェル」ページ を参照してください。
ビルドが一度トリガーされると、TFS は SharePoint アプリケーションに関連するプロジェクトをコンパイルし Windows PowerShell スクリプトを実行して、対象の SharePoint 環境にソリューションを展開します。
SharePoint アプリケーションを信頼する
ターゲット環境へのアプリケーション コンポーネントの展開後、ビルドの一部である可能性がある自動テストを含め、アプリケーションにアクセスする前に、テナント (またはサイト コレクション) 管理者が SharePoint のアプリ情報ページでアプリケーションを信頼する必要があることに注意することが重要です。 この要件は、自動ホスト型アプリと SharePoint ホスト型アプリに適用されます。 この手動プロセスは、アプリケーションが信頼されるまで、ターゲット環境へのデプロイ後に通常実行されるテストが中断されるため、ビルド プロセスの変更を表します。
クラウド ホスト型 (自動およびプロバイダー) アプリケーションの場合、開発者は SharePoint に展開されたアプリケーション パッケージとは独立して、非 SharePoint コンポーネントをクラウド ホスト型インフラストラクチャに展開することができることに注意してください。
図 10. 非 SharePoint コンポーネントの展開
[
図 10 に示すように、SharePoint アプリケーションであるソリューションに変更を加えた場合、状況によってはソリューション内のプロジェクトに加えた変更が SharePoint アプリケーション プロジェクト自体には適用されない場合があります。 このような状況では、SharePoint アプリケーション プロジェクトは変更されていないため、再表示される必要はありません。 クラウド ホスト型プロジェクトに関連する変更は再表示される必要があります。
SharePoint の外部のインフラストラクチャに展開されるアプリケーションに対する変更は、ターゲット サイト コレクションまたはテナントに展開されるアプリケーション コンポーネントとは別に行うことができます。 開発者にとって、これは、クラウドでホストされるコンポーネントを頻繁に (トリガーされた) ベースで、SharePoint アプリケーション プロジェクトとは別にデプロイするための自動ビルド プロセスを作成できることを意味します。 そのため、SharePoint のアプリ情報ページでアプリケーションのアクセス許可を承認する手動の手順は必要ないため、ビルド定義の継続的な展開とテスト プロセスを可能にします。 ソリューションの SharePoint アプリケーション コンポーネントは、このプロジェクト内の項目が変更され、再デプロイが必要な状況でのみデプロイする必要があります。
テスト
「ビルド プロセス セクション」 で説明したように、アプリケーション テストとは、アプリケーションのコンパイルおよび展開が完了したかどうかを確認する方法です。 アプリケーションのビルドと展開を確認する手段としてテストを使用することによって、チームは、品質を把握すると同時に、アプリケーション コードへの最近の変更により、いつ SharePoint アプリケーションが侵害を受けたかを知る手段を得ました。
図 11 に、SharePoint アプリケーション モデルに最適なテスト アプローチの種類を示します。
図 11. テスト アプローチ
[
図 11 は、SharePoint アプリケーションを種類ごとにテストするために、異なる種類のテストの使用を提案しています。 コード化された UI テストは、ビジネス ロジックとユーザー エクスペリエンスが同じレイヤーに存在する SharePoint ホスト型のアプリケーションに対して使用します。 ビジネス ロジックは JavaScript ライブラリに抽象化できるのに対し、そのロジックをテストする主な手段は、ユーザー エクスペリエンスを経由します。
クラウド ホスト型アプリケーション (つまり自動化およびプロバイダー ホスト型) は、完全にコード化された UI テストを使用できると同時に、ソリューションのサービス コンポーネントの検証のための単体テストも使用することができます。 これにより開発者は、機能的な観点からみて、アプリケーションのホスト型インフラストラクチャの品質に自信を持てるようになります。
以降のセクションでは、SharePoint アプリケーションに関して、コード化された UI テストとその他のテストの種類の注意点を検討します。
クライアント側コードおよびコード化された UI テスト
ビルド検証テスト (BVT) と完全なシステムテストには、コード化された UI テストが推奨されます。 これらのテストは記録済みの操作に依存して、ビジネス ロジックとアプリケーションの中間層だけでなく、ユーザー エクスペリエンスをもテストします。 クライアント側コードを使用する SharePoint アプリケーションでは、ビジネス ロジックのエントリ ポイントと実行の大半はユーザー エクスペリエンス層に存在します。 このため、コード化された UI テストは、ユーザー エクスペリエンスをテストできるだけでなく、アプリケーションのビジネス ロジックも同様にテストできます。 コード化された UI テストの詳細については、「UI オートメーションを使用したコードの検証」を参照してください。
コード化された UI テストは、多くの UX とビジネス ロジックが混在する SharePoint ホスト型アドインで使用できます。 これらのテストは、他のテストと同様に TFS のビルド定義から実行できるため、デプロイ後にアプリケーションの機能を検証できます (また、アプリケーションは SharePoint によって信頼されます)。
非コード化 UI テスト
クラウドホスト型アプリケーションなど、アプリケーションの UX レイヤーの外部にアプリケーション ロジックが存在する状況では、コード化された UI テストと非コード化された UI テストの組み合わせを活用する必要があります。 従来の単体テストなどのテストを使用して、プロバイダーホスト型インフラストラクチャに実装されているサービス ロジックのビルド品質を検証できます。 これにより、ソリューション関数のプロバイダーでホストされるコンポーネントに対する包括的な信頼を開発者に提供し、テストの観点から説明します。
Web のパフォーマンスと負荷テスト
Web のパフォーマンスと負荷テストは、開発者に、期待または予想されたユーザー負荷でアプリケーションが機能する自信を与えます。 このテストには、時間の経過に伴って合理的にスケーリングされる予測可能なユーザー ベースを同時に処理するアプリケーションの機能の決定が含まれます。 Web のパフォーマンスと負荷テストでは、コード化された UI テストおよび単体テストの両方をソースとすることができます。 ALM プラットフォームを TFS のように使い、これらのテストによってアプリケーションの負荷テストを実行します。
これらのテストを使用して SharePoint アプリケーションをテストする場合、インフラストラクチャのテストは、これらのテストの主な目標ではないことに注意してください。 インフラストラクチャは、SharePoint ホスト型でもプロバイダーホスト型でも、同様の負荷とパフォーマンスベースラインが確立されている必要があります。 アプリケーションの Web パフォーマンスとロード テストでは、インフラストラクチャの課題が強調されますが、主にアプリケーションのパフォーマンスをテストする手段と見なす必要があります。
Web パフォーマンス テストとロード テストの詳細については、「 リリース前にアプリケーションでパフォーマンス テストを実行する」を参照してください。
環境の品質とテスト
多くの組織では、物理または仮想で、相互に独立したテスト環境を複数備えています。 これらの環境は、チームの ALM プロセス、規制要件、またはその両方の組み合わせによって異なる場合があります。 チームが使用する必要があるテスト環境の数と種類を決定するために、次のガイダンスは SharePoint アプリケーションに固有の機能プラクティスに基づいていますが、ソフトウェア開発には ALM プラクティスも使用します。
開発者テスト
開発者がソリューションのコンポーネントを作成する環境では、開発者テストとなることがあります。 規模の大きいアプリケーションの異なる側面またはコンポーネントで作業している各開発者は、単体テスト、コード化された UI テスト、および開発サイトに展開されたアプリケーション コードをそれぞれ備えています。
図 12. 開発者テスト プロセス
[
開発者は、各自の Office 365 または社内開発者サイトに展開されたソリューション コンポーネントに対して、Visual Studio からテストを実行します。 クラウドでホストされるアプリケーションの場合、プロバイダーホスト型インフラストラクチャ上にあるソリューション コンポーネントに対して、Visual Studio からテストも実行されます。 これらのコンポーネントは、開発者の Microsoft Azure サブスクリプションに存在します。
この方法では、開発者が個々のOffice 365開発者サイトと Microsoft Azure サブスクリプションを持っていることを前提としています。これは、MSDN サブスクリプションを通じて提供されます。 開発者がアプリケーションをオンプレミス展開用に作成している場合でも、これらの開発者サービスは開発およびテストで使用されることがあります。
開発者がこれらのサービスを持っていない場合、または完全にオンプレミスで開発を行う必要がある場合は、オンプレミスファームの開発者サイト コレクションと開発者固有のプロバイダーホスト型インフラストラクチャに対してコンポーネントのテストを実行します。 プロバイダー向けのホスト型インフラストラクチャは、開発者専用の仮想マシンに配置することができます。 完全信頼ソリューション開発の場合は、開発者は独自の仮想 SharePoint ファームおよびプロバイダー向けのホスト型インフラストラクチャが必要となります。
統合およびシステム テスト
アプリケーションをテストするには、すべての開発コンポーネントを集中環境に集めて展開する必要があります。 この統合環境では、開発者が作成するソリューションのコンポーネントを展開して、他の開発者が書いたソリューションのコンポーネントと相互作用するところを観察する場所を提供することができます。
図 13. 統合テスト環境
[
この種のテストでは、ALM プラットフォームは SharePoint アプリケーションと必要なコンポーネントをビルドして、ターゲット環境に展開します。 これには、SharePoint でホストされているアプリケーションでは、Office 365 サイトが使えます。または、システム統合とテスト専用に設置したオンプレミス / IaaS SharePoint サイトコレクションも使えます。 SharePoint クラウドでホストされているアプリケーションでは、TFS は一元化された Microsoft Azure サブスクリプションにもコンポーネントを展開します。このサブスクリプションには、サービスはシステム統合とテスト専用に構成されます。 すると、TFS は SharePoint アプリケーションに対し UI のコードまたはユニットのテストを実行します。また、ホストのインフラストラクチャでソリューションが必要とする一切のコンポーネントについても実行します。
UAT と QA テスト
ユーザー受け入れテスト (UAT) の場合、組織には、多くの場合、統合テストとシステム テストとは別に、この機能が実行される個別の環境があります。 これらのテスト環境を分離することで、自動化された継続的リリースとテストの頻度が、ユーザーがアプリケーションの指定されたビルドに対して長時間にわたってテストを実行する可能性がある UAT アクティビティに干渉することを防ぐことができます。
図 14. UAT テスト
[
図 14 に示すように、受け入れテストまたは組織のテスト リソースを実施するために割り当てられたユーザーは、アプリケーションの適切に公開されたビルドに焦点を当てた安定した環境でテスト スクリプトを実行します。 コードのデプロイとテストは統合環境で続行されますが、ユーザーは手動テストを実行して、アプリケーションが必要な使用またはテスト ケースを満たしていることを検証します。 アプリケーションとプロバイダーでホストされるインフラストラクチャは、通常はリリース マネージャーによってこのテスト環境にデプロイされます。 自動デプロイも可能です。 この種のデプロイでは、TFS の専用の UAT ビルド定義が使用されます。これは、統合およびシステム テスト環境のデプロイを実行する 1 つを反映しています。
クラウドでホストされるインフラストラクチャの場合、統合環境とシステム テスト環境と共有される Microsoft Azure サブスクリプションへのデプロイは、サービスの名前が付けられ、異なるサービスまたはデータベースとして並行してデプロイされるように構成されている場合に可能です。 このアプローチでは、図 15 に示すように、統合とシステムのテストと UAT および QA テスト用のテスト Microsoft Azure サブスクリプションの一連のサービスとデータベースが提供されます。
図 15. 統合および UAT テスト
[
コード プロモーション プラクティス
開発環境とテスト環境と運用環境の間のコード昇格プロセスは、適切に定義されたリリース管理プロセスを使用して行う必要があります。 図 16 では、開発者は単体テストのためにソリューション コンポーネントを開発環境にデプロイします。
図 16. リリース管理プロセス
[
TFS へのチェックインの後、自動ビルド プロシージャによってソリューションがコンパイルされ、TFS のビルド定義の一部としてビルド検証テストが実行されるターゲット統合とシステム テスト環境にソリューションがデプロイされます。 このアプローチには、ソリューションのプロバイダーホストコンポーネントをターゲット環境 (Microsoft Azure またはオンプレミス環境) にデプロイすることが含まれます。 Microsoft Azure インフラストラクチャの場合、Microsoft Azure サブスクリプションは、統合テストとシステム テストの両方に使用されるサブスクリプションと、異なる名前空間と個別の SQL データベースにデプロイされていると仮定して UAT と QA の両方で使用できる点に注意してください。
リリース管理者または独立した TFS ビルド定義は多くの場合、手動で呼び出して UA または TQA 環境へ展開することができます。 このアプローチは、ユーザーがテスト対象とするビルド バージョンの管理を簡単にしてくれます。 リリース管理者は、TFS 共有からビルドを選択して、展開プロセスを各自で実行することができます。 プロモーションから実稼働まで、リリース管理は呼び出されてアプリケーションを運用環境に展開し、テストが終わるまでインストールおよびビルド検証を監視します。
アプリケーションの修正プログラムとアップグレード
Microsoft は開発者がどのようにアプリケーションをアップグレードするかについて、具体的なガイダンスを用意しています。 SharePoint プラットフォームは、ユーザーへの新しいバージョンの通知をサポートしています。
SharePoint アプリケーションのアップグレードとパッチ適用に関する戦略の確立に関する考慮事項については、「 SharePoint アドインの更新」を参照してください。
アプリケーションの変更について守るべき推奨パターンは、既存のコード開発や従来のエンジニアリング パターンと変わりません。 これには、バグ修正および機能開発、目標アプリケーション カタログへの増分展開での分岐およびマージに関する規律が含まれます。 上記のガイダンスを使用して、SharePoint 用アプリケーションの変更を完了し、それらをターゲット アプリケーション カタログまたはストアに展開できます。
SharePoint アドインの更新プロセスの情報は、SharePoint アプリケーションを更新するための手法に関する追加の戦術的なガイダンスを提供します。 これは、テスト環境内のファームにアプリケーションの更新プログラムが反映されるサイクルを短縮することによって、展開テストを加速するというものです。 さらに、この記事は、さまざまなアプリケーション展開モデル内の状態に適応する方法のガイダンスを提供します。