SharePoint Framework におけるチームベースの開発

[アーティクル]
03/21/2023

SharePoint Framework は、SharePoint カスタマイズをビルドするための新たな開発モデルです。現在利用できる他の SharePoint 開発モデルとは異なり、SharePoint Frameworkはクライアント側の開発に重点を置き、Gulp や webpack などの一般的なオープンソースツールの上に構築されています。この変更の大きな利点の 1 つは、任意のプラットフォームの開発者が SharePoint のカスタマイズを構築できることです。

SharePoint Framework は 1 つの開発モデルで、基礎となるテクノロジの違いに関わりなく、ソリューションのビルドに使用する際に、従来 SharePoint 開発者が使用してきた他の開発モデルと同じ概念が適用されます。開発者は SharePoint Framework ツールチェーンを使用してソリューションのビルドとテストを行い、準備が整うと、SharePoint テナントでさらにテストしてリリースするために展開用ソリューションパッケージを引き渡します。

SharePoint Framework はいくつかの異なるパッケージで構成されています。これらのパッケージにはそれぞれ独自のバージョンであり、SharePoint Framework のリリースを構成します。たとえば、2017年2月の SharePoint Framework の一般提供リリースは、次の v1.0.0 パッケージバージョンで構成されています。

@microsoft/sp-client-base
@microsoft/sp-core-library
@microsoft/sp-webpart-base
@microsoft/sp-build-web
@microsoft/sp-module-interfaces
@microsoft/sp-webpart-workbench

特定のリリースの SharePoint Framework を対象とするプロジェクトの場合、それぞれ適切なバージョンの種々のパッケージすべてを参照しなければなりません。新しいプロジェクトをスキャフォールディングする場合、SharePoint Framework Yeoman ジェネレーターによって、対応するリリースの SharePoint Framework から対象パッケージへの必要な参照が自動的に追加されます。ただし、プロジェクトを新しいバージョンの SharePoint Framework にアップグレードする場合、開発者は SharePoint Framework パッケージの適切な更新バージョン番号に特別な注意を払う必要があります。

開発環境の準備

SharePoint Framework ソリューション開発者を構築するには、開発マシン上の特定のツールが必要です。他の SharePoint 開発モデルと比べ、SharePoint Framework は制約が少なく、どのようなオペレーティングシステムを選択しても最も生産性の高い状態でツールを使用できます。

開発者が開発環境を構成するには、いくつかの方法があります。それぞれに異なる利点があり、開発者チームがさまざまなオプションを十分に理解することが重要です。

SharePoint Framework ツールチェーン

SharePoint Framework ソリューションをビルドするには、特定のツールセットを使用する必要があります。次の一覧は、各 SharePoint Framework 開発環境で必要な基本的ツールセットを網羅しています。

Node.js

SharePoint Frameworkには、Node.jsを開発者マシンにインストールする必要があります。 Node.jsは、プロジェクトのビルドとパッケージ化に使用されるデザイン時ツールのランタイムとして使用されます。 Node.jsは開発者マシンにグローバルにインストールされ、必要に応じて複数のバージョンのNode.jsの実行をサポートするソリューションがあります。

詳細については、「SharePoint Framework 開発環境を設定する」を参照してください。

NPM

npm は .NET プロジェクトの NuGet に相当します。これにより、SharePoint Framework プロジェクトで使用するパッケージを取得してインストールできます。また npm は、SharePoint Framework ツールチェーンをインストールするときにも使用されます。通常、開発者は最新バージョンの npm を使用し、開発者マシンにグローバルにインストールします。 Npm 自体は Node.js パッケージであるため、複数バージョンの Node.js を同時実行すると、それぞれ独自のバージョンの npm がインストールされます。

Gulp

Gulp は .NET プロジェクトの MSBuild と同等であり、SharePoint Framework プロジェクトのビルドやパッケージ化などのタスクを実行する役割を担います。 Gulp はNode.js パッケージとして配布され、通常は npm を使用してグローバルにインストールされます。

Yeoman および SharePoint Framework Yeoman ジェネレーター

開発者は、Yeoman および SharePoint Framework Yeoman ジェネレーターを使用して新しい SharePoint Framework プロジェクトを作成します。 Yeoman とそのジェネレーターはどちらも Node.js パッケージとして配布され、通常、npm を使用してグローバルパッケージとしてインストールされます。グローバルインストールの利点として、開発者が Yeoman とジェネレーターを一度にインストールし、それらを使用して簡単に新しいプロジェクトの作成できるという点があります。

SharePoint Framework Yeoman ジェネレーターは特定の SharePoint Framework バージョンと関連付けられています。ジェネレーターを使用してスキャフォールディングされたプロジェクトは、特定のバージョンの SharePoint Framework パッケージを参照し、生成された Web パーツは対象フレームワークの特定部分を参照します。 SharePoint Framework Yeoman ジェネレーターは新しいプロジェクトを作成するためだけでなく、Web パーツを既存のプロジェクトに追加するときにも使用されます。グローバルにインストールし、過去に作成した既存のプロジェクトに新しい Web パーツを追加する必要がある場合、新しく作成された Web パーツは、ビルドエラーにつながる可能性があるプロジェクトの残りの部分と一致しない可能性があります。この制限を回避するには、いくつかの方法があります。この記事では後で説明します。

TypeScript

SharePoint Frameworkでは、TypeScript を使用して、開発中に既にエラーをキャッチすることで、開発者の生産性を高めることができます。 SharePoint Framework プロジェクトには独自のバージョンの TypeScript が付属しています。これはビルドプロセスで使用され、開発者が個別にインストールする必要はありません。

SharePoint Framework 開発環境のビルド

以前は、SharePoint 開発者は仮想マシンを開発環境として使用することが一般的でした。仮想マシンを使用すると、ビルドするソリューションを、特定の組織が使用する環境で確実に動作させることができました。仮想マシンでは、開発者は SharePoint をインストールして、特定の組織が使用する運用環境と同じレベルに合わせて調整しました。場合によっては、ソリューションが可能な限り密接に実行されるターゲット環境に合わせて、追加のソフトウェアをインストールします。この方法では、異なる環境で生じるエラーを早期にキャッチできるものの、複雑さや各種環境を管理しなければならないという欠点もありました。

クラウド用ソリューションの開発に移行しても、部分的にしか問題は解決しませんでした。開発者は SharePoint ファームを開発マシンで実行する必要はなくなりましたが、ソリューションがホストされる方法や、SharePoint Online と通信する方法について考慮する必要が生じました。

SharePoint Frameworkクライアント側の開発に重点を置いているため、開発マシンに SharePoint をインストールする必要はなくなりました。わずかな例外を除き、フレームワークと他のパッケージに対するすべての依存関係はプロジェクトで指定され、プロジェクトフォルダーに入れられます。 SharePoint Frameworkはクラウドに起源があり、頻繁に進化するため、開発者は、SharePoint Framework プロジェクトに対応する適切なバージョンのツールチェーンを使用していることを確認する必要があります。

共有または個人用の開発環境

SharePoint カスタマイズは、ページに直接追加される簡単なスクリプトから、ソリューションパッケージとして展開される高度なソリューションまで、幅広い範囲に及びます。 SharePoint Framework は、SharePoint カスタマイズの構造化されて繰り返し使用できる開発モデルを対象とする開発モデルです。 SharePoint Framework ソリューションをビルドするとき、チームの各開発者は独自の開発環境を使用し、プロジェクトのソースコードを、ソース管理システムを介してチームの他の開発者と共有します。これにより、開発者は同じプロジェクトで同時に作業し、互いの生産性に影響を与えずにソリューションをテストできます。

以前は、多くの組織が SharePoint 開発者に強力な開発マシンを提供することを正当化することは困難でした。場合によっては、複数の開発者が生産性を犠牲にして同じマシンを共有する必要がありました。 SharePoint Frameworkを使用すると、開発者は市場標準の開発者マシンを使用して SharePoint のカスタマイズを構築できます。

ホスト上での開発

おそらく、SharePoint Framework プロジェクトの開発環境を設定する最も簡単なオプションは、すべてのツールをホストコンピューターに直接インストールすることです。チームが SharePoint Framework プロジェクトでのみ作業している場合、Node.js を各自のマシンにインストールできます。他のNode.js プロジェクトで作業する場合は、 nvm などのサードパーティソリューションを使用して、複数のバージョンのNode.jsを並行して実行できます。

SharePoint Framework ツールチェーンで必要なツールに続いて、開発者は Yeoman と SharePoint Framework Yeoman ジェネレーターをインストールします。通常、これら両方のツールはグローバルにインストールされます。ただし、SharePoint Framework Yeoman ジェネレーターが特定のバージョンの SharePoint Framework に関連付けられていて、開発者が異なるバージョンで作成されたプロジェクトで作業する必要がある場合、その時点で作業している特定のプロジェクトに固有のジェネレーターバージョンをアンインストールしてからインストールする必要があります。より実際的な方法は、対象プロジェクトで Yeoman をグローバルに、SharePoint Framework Yeoman ジェネレーターをローカルにインストールすることです。その場合には若干のオーバーヘッドが生じますが、開発者は、今後、対象プロジェクトに新しい要素を追加しなければならない場合に、プロジェクトの残りの部分と互換性を確保できます。

ホストで開発する利点は、開発者が自分のコンピューターを自分の好みに合わせて 1 回構成し、すべてのプロジェクトで使用できることです。また、ソフトウェアがホスト上で実行されると、その間に仮想化レイヤーがない CPU、メモリ、ディスク I/O に直接アクセスでき、仮想化された同じソフトウェアを実行する場合よりもパフォーマンスが向上します。

仮想マシンにおける開発

以前の SharePoint 開発者の間で最も一般的なアプローチは、SharePoint ソリューションを構築するための主要な開発環境として仮想マシンを使用することでした。仮想マシンを使用すると、開発者は各種プロジェクトの異なる要件に適応できました。

SharePoint Framework でソリューションをビルドすると、これまで SharePoint ソリューションをビルドする際に使用していたのと同じ利点を活用できます。仮想マシンを使用すると、開発ソフトウェアをホストオペレーティングシステムから分離できます。これは、特に大規模な組織で一般的な要件です。プロジェクト開発者ごとに個別の仮想マシンを作成することで、将来特定のプロジェクトを選択する必要がある場合でも、使用するツールチェーンがプロジェクトと互換性があることを確認できます。

仮想マシンの使用には欠点はありません。仮想マシンは大規模であり、開発者は、生産性を高めるために許容されるパフォーマンスで実行するのに十分な強力なコンピューターを使用する必要があります。さらに、特に長期間にわたって、開発者はオペレーティングシステムを最新の状態に保ち、必要なすべてのセキュリティ更新プログラムを確実に実行する必要があります。開発者は仮想マシンで作業する際に、新しいプロジェクトの開始時に時間を費やして、自分の好みに合わせて標準仮想マシンを構成するか、生産性を犠牲にして標準セットアップに渡す必要があります。仮想マシンは、すべてのコンポーネントを含む完全なオペレーティングシステムを実行するため、チーム内のすべての開発者が使用するすべての仮想マシンの整合性を確保することがはるかに困難です。 SharePoint Framework ソリューションをビルドするために仮想マシンを使用すると、他のタイプの開発環境に比べて、コストと時間の両面において高価になります。

Docker を使用した開発

ホスト上での開発と仮想マシンにおける開発の中間的位置にあるのが、Docker を使用する方法です。 Docker は、いくつかの違いがある仮想マシンに似たソフトウェア仮想化テクノロジです。仮想マシン上で Docker イメージを使用する最も重要な利点は、Docker イメージの作成、保守、分散が容易で、軽量 (仮想マシンに必要な数十 GB のディスク領域に比べて数百 MB) であり、開発者はホストマシンに既にインストールおよび構成されているツールと基本設定を使用できるようにすることです。

仮想マシン同様、Docker コンテナーはオペレーティングシステム (最も一般的には Linux ベース) の仮想化インスタンスを実行します。コンテナーを作成するために使用される、イメージ内にインストールされているソフトウェアすべては、そのコンテナー内で独立した状態で実行され、対象コンテナーと明示的に共有されるホストファイルシステム部分にのみアクセスします。 Docker コンテナー内部のファイルシステムに対するすべての変更はコンテナーが閉じると破棄されるので、開発者はホストのフォルダーを共有してソースコードを格納します。

詳細については、SharePoint Framework ソリューションをビルドするための Docker の使用法を確認してください。

SharePoint Framework プロジェクトにおける開発ワークフロー

SharePoint Frameworkはオープンソースツールチェーンに基づいており、同じスタック上に構築された他のプロジェクトに存在する一般的な開発ワークフローに従います。一般的な SharePoint Framework プロジェクトで、そのワークフローがどのようになるかを、以下に説明します。

新しい SharePoint Framework プロジェクトの作成

SharePoint Framework を使用して SharePoint カスタマイズをビルドする場合、新しい SharePoint Framework プロジェクトをスキャフォールディングするのが最初のステップです。これは、SharePoint Framework Yeoman ジェネレーターを使用して実行します。ジェネレーターによって、プロジェクトの名前や場所に関するいくつかの質問に対する答えを求めるダイアログが表示されます。また、最初の Web パーツまたは拡張情報を作成することもできます。コンポーネントごとに別の JavaScript フレームワークを自由に選択できますが、通常は SharePoint Framework プロジェクトごとに 1 つのフレームワークを使用することをお勧めします。

依存関係バージョンのロック

SharePoint Framework Yeoman ジェネレーターによってスキャフォールディングされた新しいSharePoint Framework プロジェクトには、SharePoint Framework パッケージと、正しく実行するために必要なその他のパッケージに依存関係があります。 Web パーツをビルドするときに、Angularや jQuery などの追加の依存関係を含めることができます。 SharePoint Frameworkプロジェクトでは、npm を使用して依存関係がインストールされます。各依存関係は、特定のバージョンのNode.js パッケージです。既定では、依存関係はバージョン範囲を使用して参照されます。これは、開発者が依存関係をより簡単に最新の状態に保つために役立ちます。この方法の結果として、同じプロジェクトの依存関係を 2 つの時点で復元すると、異なる結果が得られます。これにより、プロジェクトが破損する可能性があります。

オープンソースツールチェーンでビルドされたプロジェクトの途中で依存関係が変更されるというリスクを回避するための一般的な解決策は、すべての依存関係のバージョンをロックするという方法です。プロジェクトに依存関係を追加するときに、開発者は、npm インストール コマンドに --save-exact 引数を指定して呼び出すことによって、バージョン範囲ではなく、特定のバージョンの依存関係をインストールできます。

ただし、これは特定のパッケージの子依存関係には影響を及ぼしません。プロジェクト内のすべてのバージョンの依存関係とその子を効率的にロックするには、NPM でサポートされているネイティブのロックファイル機能を使用できます。詳細については、「npm-パッケージのロック: NPM ロックファイルの説明」を参照してください。

ソース管理へのプロジェクトの追加

チームの他のメンバーが同じプロジェクトで作業できるようにするには、チームが使用しているソース管理システムに対象プロジェクトを追加します。チームが使用するシステムによって、詳細なステップは異なります。

SharePoint Framework プロジェクトは、.gitignore ファイルを使用してスキャフォールディングされます。このファイルには、ソース管理から除外する必要があるファイルが記述されています。 Git 以外のソース管理システム (Team Foundation System リポジトリを使用した Visual Studio Team System など) をチームで使用している場合、ソース管理にプロジェクトの適切なファイルを含めていることを確認しなければなりません。また、依存関係と、ビルドプロセスで自動生成されたファイルを除外すると、チームの作業効率が上がります。

ソース管理に含めないように特に注意する必要がある場所の 1 つは、node_modules フォルダーです。このフォルダーには、プロジェクトが依存するパッケージと、npm インストール コマンドを使用して依存関係を復元するときに自動的にインストールされるパッケージが入っています。一部のパッケージは、バイナリにコンパイルされます。このコンパイルプロセスはオペレーティングシステムに依存しています。チームが異なるオペレーティングシステムで作業している場合は、ソース管理に node_modules フォルダーを含めると、一部のチームメンバーのビルドが壊れる可能性があります。

ソース管理からのプロジェクトの取得

ソース管理から初めてプロジェクトを取得するときに、プロジェクトのソースコードは取得できますが、プロジェクトのビルドに必要な SharePoint Framework ライブラリはまったく取得できません。 .NET プロジェクトで NuGet パッケージを使用して作業する場合と同様、最初に依存関係を復元する必要があります。 SharePoint Framework プロジェクトでは、Node.js の上にビルドされる他のすべてのプロジェクト同様、コマンドラインで npm インストール を実行します。 NPM は package.json ファイルからの情報と package-lock.json ファイルからの情報を組み合わせて使用し、すべてのパッケージをインストールします。

注:

通常、npm インストール コマンドを使用して依存関係を復元するには、https://registry.npmjs.org からパッケージをダウンロードするためにインターネット接続が必要になります。

ネットワーク接続で問題が発生する場合、または npmjs レジストリを利用できない場合には、ビルドが失敗します。この制限を緩和する方法がいくつかあります。 1 つの方法は、shrinkpack を使用してすべての依存関係の tarball をダウンロードし、ソース管理に格納することです。 Shrinkpack は npm-shrinkwrap.json ファイルを自動的に更新して、プロジェクトの依存関係のオフラインインストールを可能にするローカル tarball を使用します。

一部のパッケージは、インストールプロセス中にバイナリにコンパイルされます。このコンパイルプロセスは、アーキテクチャとオペレーティングシステムに固有です。 Linux を実行する Docker コンテナーで依存関係を復元し、Windows ホスト上でプロジェクトをビルドしようとすると、バイナリをビルドして実行するために使用する環境の種類が異なることを報告するエラーを受け取ります。

チームでソリューションを開発する過程で、新しい依存関係または更新された依存関係がプロジェクトに追加されることがあります。ソース管理からプロジェクトを最後に取得した後に package.json ファイルが変更された場合、コマンドラインで npm install を実行して、不足している依存関係をインストールする必要があります。 package.json ファイルが変更されたかどうか不確かな場合、コマンドラインで npm install を実行することによって、プロジェクトに悪影響を与えることなく、最新の依存関係があることを確認できます。

プロジェクトへのパッケージの追加

既存のパッケージを使用して特定のタスクを実行すると、生産性を高めることができます。 https://www.npmjs.com は、プロジェクトで使用できるパッケージの公開レジストリです。

重要

パッケージを https://www.npmjs.com に公開する前に行う公式な検証プロセスはないため、特定のパッケージが使用可能かどうかをコンテンツとライセンスの両面から注意深く調べる必要があります。

SharePoint Framework プロジェクトにパッケージを追加するには、コマンドラインで npm install {package} --save または npm install {package} --save-dev コマンドを実行します (例: npm install angular --save)。 --save または --save-dev 引数を使用すると、パッケージは package.json ファイルに確実に追加され、チームの他の開発者も同様に、依存関係を復元するときにそれを取得します。このようにしないと、自分以外のマシンでプロジェクトをビルドすると失敗します。 Angular や jQuery など、ランタイムで、ソリューションが必要とするパッケージを追加する場合、--save 引数を使用する必要があります。追加の gulp タスクなどの、ビルドプロセスで必要なパッケージは、--save-dev 引数を付けてインストールしなければなりません。

パッケージをインストールするときに、バージョンを指定しないと、npm はパッケージレジストリ (既定では https://www.npmjs.com) で使用可能な最新バージョンをインストールします。これは通常、使用したいバージョンです。パッケージのバージョンを開発者が指定する必要があるケースの 1 つは、npm-shrinkwrap.json を使用していて、既存のパッケージを新しいバージョンにアップグレードする場合です。既定では、npm は npm-shrinkwrap.json ファイルにリストされているバージョンをインストールします。 npm install コマンド (npm install angular@1.5.9 --save など) でバージョン番号を指定すると、対象パッケージがインストールされ、npm-shrinkwrap.json ファイルのバージョン番号が更新されます。

内部パッケージの操作

チームがクライアント側ソリューションを開発する過程で、プロジェクト全体で再利用するコードの共通ライブラリをビルドする可能性は高いでしょう。多くの場合、そのようなライブラリには、運用環境に展開されるバンドル以外に、組織外で公に共有されることのない専用コードも含まれます。 SharePoint Framework プロジェクトを扱うときに、チームがプロジェクトで内部ライブラリを活用するための方法がいくつかあります。

プライベートパッケージレジストリのホスティング

以前は、.NET ソリューションをビルドした多くの組織で NuGet プライベートリポジトリをホスティングし、内部パッケージ用に NuGet パッケージ管理システムを活用してきました。 SharePoint Framework はパッケージ管理に npm を使用するため、組織は同様に、内部パッケージにプライベートレジストリを使用できます。内部で開発されたパッケージはプライベートレジストリに公開され、組織内のすべてのプロジェクトで使用されます。

プライベートパッケージレジストリを使用するとき、組織は、クラウドでホスティングされる各種のオファリングの中から選択するか、または組織独自のインフラストラクチャで独自のレジストリをホスティングすることができます。

プライベートパッケージレジストリを使用すると、各種のパッケージで使用される共通コードの管理に集中できます。組織は、共有コードベースに対する変更についての別個の管理計画を定義すると、高品質のコードライブラリを確保し、コードライブラリによるプロジェクトの処理速度の低下という重荷を負わせることなく、すべての開発者に意図どおりの利点を提供できます。

Visual Studio Team Services または Team Foundation Server を使用する組織では、簡単に VSTS/TFS で直接、プライベート npm レジストリを作成できます。他のソース管理システムを使用する組織では、他のソリューションを使用してパッケージをホストできます。クラウドでホスティングされる人気のあるプライベートレジストリは npm Enterprise です。組織自体でレジストリをホスティングすることに関心がある場合、Sinopia またはその枝分かれである Verdaccio、あるいは Nexus などの多数あるオープンソース実装から選択できます。

注:

プライベートパッケージレジストリをホスティングするためのエンジンが異なると、開発ステージも異なるため、ご使用の要件を満たすエンジンについて、機能、ライセンス、サポートのそれぞれの面から注意深く評価する必要があります。

プライベートパッケージレジストリのインストールと管理を簡単にするため、ほとんどのエンジンにはすぐに使用できる Docker イメージが備わっています。

npm リンクを使用したパッケージのリンク設定

プライベートレジストリを使用する以外の方法は、パッケージのリンクを設定することです。レジストリをセットアップする必要はありませんが、すべての開発者マシンとビルドサーバーを慎重に調整しなければなりません。

最初に、チームのすべての開発者がそれぞれの開発マシンで共有パッケージのコピーを入手する必要があります。各開発者は、コマンドラインで、作業ディレクトリをいずれかの共有パッケージに変更してから、npm link コマンドを実行します。このコマンドは、特定のパッケージを、特定の開発マシンでグローバルパッケージとして登録します。次に、各開発者は、共有パッケージを使用するプロジェクトのディレクトリに作業ディレクトリを変更します。その後、コマンドラインで npm install {shared_package} --save コマンドを実行して、他のパッケージをインストールするのと同じ方法でパッケージをインストールします。共有パッケージはグローバルにインストールされるので、npm は、パッケージのインストールソースとして対象バージョンを使用します。この時点で、プロジェクトの観点からは、パッケージは他のパブリックパッケージと同様にインストールされます。開発者は、パッケージをプロジェクトにバンドルする方法を選択できます。

パッケージのリンク設定は、すべての開発マシンとビルドサーバーで実行する必要があります。共有パッケージを npm link コマンドを使用してリンク設定しないと、プロジェクト依存関係の復元に失敗し、ビルドできません。

リンク設定されたパッケージの参照は、共有パッケージとプロジェクトを同時に開発する場合に、プロジェクトの早い段階で役立ちます。リンク設定されているおかげで、プロジェクトで最新のコードを使用するためにパッケージの新しいバージョンをレジストリに公開する必要がありません。留意すべきリスクの 1 つとして、ローカルに変更を加え、ソース管理にまだコミットしていない共有ライブラリのバージョンを開発者が参照すると、他のチームメンバーのビルドが壊れることになります。

プライベートパッケージレジストリとパッケージのリンク設定の組み合わせ

パッケージのリンク設定は、プライベートレジストリと組み合わせて使用できます。たとえば、開発者がリンクされたパッケージを参照し、ビルドサーバーが共有ライブラリをプライベートレジストリからプルする方法で作業できます。プロジェクト側からすると、何も変わっていないように見えます。package.json ファイルのパッケージ参照は、リンクされたパッケージとプライベートレジストリのどちらからも解決できます。チームで念頭に置いておくべき唯一の点は、ビルドを実行する前に、共有ライブラリに対する最新の変更内容をプライベートレジストリに公開するということです。

共有ライブラリのコードは時経つうちに安定し、特定のプロジェクトの必要に応じて変更を加える必要は減っていくので、多くの場合に開発者は公開されたパッケージを変更するのではなく、プライベートレジストリから参照するだけで済みます。

コードの整合性と品質の確保

ソフトウェア開発チームでよく課題となるのは、プロジェクトの整合性と高品質を維持する点です。開発者ごとにコーディングスタイルと好みが異なります。どのチームにも、熟練した開発者と、特定のドメインで経験の少ない開発者が存在します。また、多くの組織や業種にはソフトウェアが準拠する必要がある特定の規制があります。これらの課題すべてによって、開発者が計画どおりに物事を進めることが難しくなります。特に、期日が近づくと、開発者は品質を犠牲にして物事を進める傾向があります。そのようにすると、長期的観点からは期日に間に合わないよりも害が大きくなります。

チームにおける JavaScript ライブラリの選択とコーディング標準の使用

チームがこれまでに SharePoint カスタマイズをビルドした経験がある場合、カスタマイズのビルド方法やプロジェクトで使用するツールとライブラリを定めたコーディング標準が存在する可能性があります。コーディング標準を使用すると、コードから各開発者の個人的な嗜好を排除し、チームの他のメンバーが簡単に採用できるようになります。また、コーディング標準は長年にわたって積み上げられてきたチームの経験を反映するため、カスタマイズのビルド効率と品質を向上できます。

現在使用できる他の SharePoint カスタマイズモデルとは異なり、SharePoint Frameworkはクライアント側の開発に重点を置いています。厳密には必須ではありませんが、SharePoint Frameworkでは、開発者がより良いコードを記述し、ビルドプロセスに既に存在する不整合をキャッチするのに役立つ TypeScript を使用することをお勧めします。また、同じタスクを実行するために使用できるクライアント側ライブラリも数百あります。チームが過去にクライアント側の開発を行った場合は、既に特定のライブラリを優先している可能性があります。そうでない場合は、最も人気のあるライブラリをいくつか調べ、チームまたはできれば組織全体用にライブラリを選ぶことは非常に有益です。

すべてのプロジェクトで同じライブラリを使用することによって、新たなチームメンバーが容易に作業に加わり、プロジェクト間でチームメンバーを交換できます。クライアント側の開発で経験を積むにつれて、組織はすべてのプロジェクトにおいてその恩恵を受けることができるようになります。また、組織全体でプロジェクトを標準化すると、配信までの時間を短縮し、プロジェクトの維持コストを抑えることができます。新たなライブラリが日々、インターネット上に公開されているため、さまざまな最新のライブラリを代わる代わる使用すると、質の悪いソリューションを非効率的な方法で配信することになります。

また、組織で使用するライブラリを標準化すると、ソリューションのパフォーマンスを最適化できます。組織全体で同じライブラリが使用されるため、ユーザーは一度ライブラリをダウンロードするだけで済みます。ソリューションの読み込み時間が大幅に加速し、結果としてユーザーエクスペリエンスが向上します。

有名ないずれかのライブラリを選択すると、そのライブラリを長期にわたり使用し、これから経験する可能性が高い多くの問題を既に解決してきた他の開発者の知識と経験を再利用できます。また、そのような人気のあるライブラリには、チームが採用できるコーディング標準が存在します。特定のライブラリに関する既存の市場標準を使用すると、組織が新たに開発者を雇用し、それらの開発者の生産性を時間をかけずに高めることによって、チームを容易に成長させることができます。

たとえば、SharePoint Framework のファーストパーティソリューションをビルドするため、Microsoft は React を選択しました。また OneDrive や Delve などの Microsoft の多数の他のチームもプロジェクトで React を使用しています。これはご使用の SharePoint Framework プロジェクトでも React を使用する必要があるということではありませんが、組織で動作するクライアント側ライブラリの選択の重要性を示しています。たとえば、チームで Angular または Knockout の使用経験がある場合には、SharePoint Framework ソリューションをビルドするときにその経験を活かし、生産性を維持できます。

ソリューションのライフサイクル全体にわたるコーディング標準とポリシーの適用

コーディング標準を使用することには確かに利点がありますが、単にコーディング標準を設定するだけでは、SharePoint カスタマイズの開発とテストのプロセス全体でそれらの標準を積極的に使用することにはなりません。開発者の対応が遅れるほど、チームのコーディング標準と組織のポリシーにソリューションが準拠していることをチームが検証するのは困難になり、プロジェクトで発見された欠陥を修正するためのコストも高くなります。 SharePoint ソリューションに対する管理計画を適用するために、開発プロセスの一環としてチームが使用するべきいくつかの手段を以下に記します。

lint 実行

lint 実行は、コードが特定の規則に従っていることを検証するプロセスです。既定では、SharePoint Framework プロジェクトは TypeScript を使用してビルドされます。 TypeScript の lint プログラムである TSLint は、それぞれのビルド時に、事前定義されているルールセットに照らしてプロジェクトを分析し、不整合を報告します。開発者は、有効にするルールを選択し、必要な場合にはチームまたは組織のガイドラインを反映する独自のルールを作成できます。

開発者は linting を使用して、TypeScript ファイルの内容だけでなく、検証することもできます。 CSS、JavaScript、Markdown などのほとんどの一般的な言語で使用できるリンターがあり、チームにこれらの言語の特定のガイドラインがある場合は、開発者がプロジェクトをビルドするたびに自動的に検証できるように、リンターに実装すると便利です。

自動化されたテスト

自動テストを使用すると、開発者は、プロジェクトに最新の変更を適用した後、すべての要素が期待どおりに動作し続けるかどうかを簡単に確認できます。プロジェクトが拡大するにつれて、自動テストの重要性が増します。コードベースを拡張すると、すべての変更に大きな影響と、他のいくつかのコードに影響を与えるリスクがあります。自動テストを使用すると、開発者はソリューションが正しく動作することを確認し、考えられる問題を早期にキャッチできます。

SharePoint Framework には、Karma テスト実行プログラムと、開発者がテストの作成に使用できる Mocha フレームワークのための標準サポートが備わっています。必要な場合には、開発者は Jest や PhantomJS などの SharePoint Framework に付属の他のツールを使用して、テスト範囲を広げることができます。 SharePoint Framework プロジェクト内のすべてのテストは、標準の gulp test タスクを使用して実行できます。

コード分析

lint 実行は特定のファイルの構文を検証するのに役立ちますが、プロジェクト全体がガイドラインに従っていることを検証するために、開発者は多くの場合、さらなるサポートを必要としています。一般に、lint プログラムはコード自体に焦点を当てますが、特定のコードファイルが示すコンテキストには注目しません。 SharePoint Framework ソリューションでは、成果物には特定の要件があります。たとえば、Web パーツはプロジェクト内で一意の ID を持っている必要があります。また、組織には、CDN からスクリプトを参照しない、決められたライブラリの特定のバージョンのみを使用するなどの要件がある場合があります。このような場合、lint プログラムでは不足で、他のツールが必要になります。

SharePoint Code Analysis Framework (SPCAF) は、SharePoint カスタマイズが組織の品質ガイドラインを満たしていることを検証するために、品質保証とセキュリティの役割を担う SharePoint 開発者、管理者、従業員がよく使用するサードパーティ製ソリューションです。 SPCAF はアプリケーションのライフサイクルプロセス全体を統合して、組織が SharePoint カスタマイズの全体としての所有コストを減らすことができます。 SPCAF には、SharePoint Framework ソリューションを特に対象としたルールセットがあります。

SharePoint Framework プロジェクトのアップグレード

通常、運用環境に SharePoint カスタマイズを展開するだけで、ライフサイクルが終わるということはありません。ソリューションの変更に先立って、要件が変更されたり、新しい要件が追加されたりすることがよくあります。以前に運用環境に展開したカスタマイズを適切に更新するには、開発者はいくつかの事柄を考慮する必要があります。

セマンティックバージョン管理 (SemVer)

若干の例外があるものの、SharePoint Framework ではバージョン番号を追跡するためにセマンティックバージョン管理 (SemVer) を使用します。セマンティックバージョン管理は、世界中のソフトウェア開発者の多くが採用しているバージョン管理パターンです。 SemVer 番号は MAJOR.MINOR.PATCH の 3 つの番号とオプションのラベルで構成され、1.0.1 などとなります。

注:

現在 SharePoint Frameworks でサポートされているのは、ラベルのない 3 つの番号のみです。

SemVer 番号の各部分は、ソリューションに追加される変更の種類に応じて次のように増加します。

MAJOR は、下位互換性がない変更の場合
MINOR: 下位互換性がある新しい機能が導入された変更の場合
PATCH: 下位互換性があるバグ修正プログラムによる変更の場合

SemVer は単に規約に過ぎないことを念頭に置いてください。最新リリースにおける変更内容を明確にするためにこの規約に従うかどうかはチームで決定できます。

セマンティックバージョン管理に関する詳細については、http://semver.org をご覧ください。

バージョン番号の増加

SharePoint Framework ソリューションの一部を更新する場合、開発者は関係する部分のバージョン番号を増やし、変更された要素と、その変更によってどんな影響があるかを明確にする必要があります。

package.json のパッケージバージョンの増加

SharePoint Framework パッケージは Node.js パッケージと同様に構造化されています。その依存関係とメタデータは、プロジェクトフォルダー内の package.json ファイルに格納されます。 package.json ファイルのプロパティの 1 つが、プロジェクト全体のバージョンを示すバージョンプロパティです。既定では、現在のソリューションのすべてのコンポーネントは、このバージョン番号をそのまま継承します。開発者は、プロジェクトの新しいリリースが計画されるたびに SemVer 規約に従って package.json ファイル内のバージョン番号を増やす必要があります。

package-solution.json 内のソリューションパッケージバージョンの増加

SharePoint Framework ソリューションは、SharePoint テナントのアプリカタログにインストールされている *.sppkg ファイルを使用してデプロイされます。 *.sppkg ファイルは SharePoint アドインパッケージに似ていて、同じバージョン管理規則に従います。 *.sppkg パッケージの現在のバージョンは、4 部構成 (MAJOR) を使用して定義されています。マイナー。リビジョン。config/package-solution.json ファイルに格納されている BUILD) 番号。わかりやすくするため、開発者は、この番号を package.json ファイルのバージョン番号と同期し、両方の番号ともプロジェクト全体のバージョンを表すようにします。

注:

SharePoint で新しいバージョンのパッケージが適切に展開されるようにするには、次のリリースまでの間に package-solution.json ファイルのバージョン番号を増やす必要があります。

依存関係の更新

SharePoint Framework プロジェクトを更新する 1 つの理由は、Angular がバグ修正やパフォーマンスの改善のために新しくリリースされたなど、基礎となる依存関係のいずれかにおける変更です。チームが依存関係のバージョンをロックするために npm shrinkwrap を使用する推奨されるアプローチに従っている場合は、 npm install {package}@{version} --save コマンドを使用して依存関係を特定のバージョンに更新し、プロジェクトをテストして、最新の更新プログラムで期待どおりに動作することを確認します。基礎となる依存関係に対する変更がプロジェクトに与える影響によって、プロジェクト全体の更新が修正プログラムだけで済む場合やメジャーリリースが必要になる場合などさまざまです。

重要

package.json ファイル内の依存関係のバージョン番号を手動で変更しないでください。 npm shrinkwrap などのロックファイルを使用している場合、 package.json ファイルに対する手動変更は無視され、代わりにロックファイルに記録されたバージョン番号が使用されるため、プロジェクトのエラーを追跡するのが困難になります。

プロジェクト構造の変更への注意

プロジェクトを SharePoint Framework の新しいバージョンに更新すると、プロジェクト構造やプロジェクトの構成ファイルへの変更が必要になる場合があります。プロジェクトの依存関係で SharePoint Framework のバージョンを更新する前に、必ずアップグレードする SharePoint Framework のバージョンを使用して新しいプロジェクトを作成し、その構造と内容を既存のプロジェクトと慎重に比較する必要があります。そうすれば、その更新がプロジェクトに及ぼす影響を判断でき、プロジェクトに影響する重大な変更を適用してしまうことを防ぐのに役立ちます。

npm outdated の使用上の注意

プロジェクト内で更新の必要がある依存関係を見極める 1 つの方法は、npm outdated コマンドを実行することです。このコマンドにより依存関係ツリーをスキャンし、更新すべきパッケージを表示できます。このコマンドの使用は便利ですが、慎重に行う必要があります。

SPFx v1.3 以降では、SharePoint Framework Yeoman ジェネレーターを使用して、SharePoint Online でのみ動作するプロジェクトをスキャフォールディングするか、または SharePoint 2016 Feature Pack 2 以上と SharePoint Online 両方で動作するプロジェクトをスキャフォールディングするかを選択できます。オンプレミスでホストされている SharePoint では、SharePoint Online で使用可能な最新のバージョンより古いバージョンの SharePoint Framework を使用します。オンプレミスの SharePoint と互換性のあるプロジェクトにnpm outdated コマンドを実行すると、中心的な SharePoint Framework パッケージをすべて、npm に発行された最新のバージョンに更新するよう推奨される場合があります。しかし、これらのパッケージを最新バージョンに更新することにより、プロジェクトがオンプレミスの SharePoint で機能しなくなることがあります。 SharePoint Framework パッケージのバージョンを更新する前に、オンプレミスでホストされている SharePoint でプロジェクトを動作させるかどうか、またその場合に、サポートする必要がある SharePoint Framework のバージョンを必ず確認してください。

リリースモードでのプロジェクトのビルドとパッケージ化

ソリューションが予期どおりに動作することを検証したら、gulp bundle --ship コマンドを使用してプロジェクトをリリースモデルでビルドします。次に、gulp package--ship コマンドを使用して、新しいパッケージを作成します。 gulp bundle --ship コマンドを先に実行しないと、パッケージには以前のバージョンのプロジェクトが入ります。

新しいバージョンのソリューションの展開

プロジェクトのビルドとパッケージ化の後、次のステップとしてプロジェクトを展開します。最初に、プロジェクトの ./temp/deploy フォルダーにある、更新済み Web パーツバンドルを展開します。以前のバージョンのソリューションの Web パーツバンドルの隣にあるファイルを公開します。

注:

以前のバージョンのソリューションは、それらを使用する Web パーツインスタンスがアクティブである限りは、削除しないでください。各バージョンのバンドルファイルには一意の名前があり、Web パーツを更新する前に前のバージョンを削除すると、それらの Web パーツが破損します。

次に、新しいソリューションパッケージを SharePoint アプリカタログに展開します。これは、適用する必要がある新しいバージョンのソリューションを SharePoint に通知するために必要です。

SharePoint Framework におけるチーム ベースの開発