フロントエンドパイプラインを使用したサイトの開発 developing-site-with-front-end-pipeline
フロントエンドパイプラインを使用すると、 フロントエンド開発者の自主性が高まり、開発プロセスを大幅に加速できます。このドキュメントでは、このプロセスがどのように機能するかと、このプロセスの可能性を最大限に引き出すために知っておくべきいくつかの考慮事項を説明します。
フロントエンドビルドコントラクト front-end-build-contract
フルスタックビルド環境と同様に、フロントエンドパイプラインには独自の環境があります。次のフロントエンドビルドコントラクトが守られている限り、開発者はこのパイプラインをある程度柔軟に使用できます。
フロントエンドパイプラインでは、フロントエンド Node.js プロジェクトでデプロイするビルドを生成するために、build
スクリプトディレクティブを使用する必要があります。これは、Cloud Manager がコマンド npm run build
を使用して、フロントエンドビルドに対してデプロイ可能なプロジェクトを生成するためです。
dist
フォルダーの結果のコンテンツは、最終的には Cloud Manager によってデプロイされ、静的ファイルとして提供されます。これらのファイルは AEM の外部でホストされますが、デプロイ済み環境の /content/...
URL 経由で使用可能になります。
ノードのバージョン node-versions
フロントエンドビルド環境は、次の Node.js バージョンをサポートしています。
- 12
- 14(デフォルト)
- 16
- 18
NODE_VERSION
環境変数を使用して、目的のバージョンを設定できます。
唯一の情報源 single-source-of-truth
一般的なベストプラクティスは、AEM に何がデプロイされているかに対する、唯一の情報源を維持することです。Cloud Manager の目的は、その唯一の情報源を明確にすることです。ただし、フロントエンドパイプラインではコードの一部の場所を分離できるため、フロントエンドパイプラインを正しく設定する必要が出ます。同じ環境の同じサイトにデプロイするフロントエンドパイプラインを複数作成しないように注意する必要があります。
このため、特に複数のフロントエンドパイプラインを作成する場合は、次のような体系的な命名規則を維持することをお勧めします。
package.json
ファイルのname
プロパティで定義されるフロントエンドモジュールの名前には、適用先のサイトの名前を含める必要があります。例えば、/content/wknd
の場所にあるサイトの場合、フロントエンドモジュールの名前はwknd-theme
のようになります。- フロントエンドモジュールが他のモジュールと同じ Git リポジトリを共有する場合、そのフォルダーの名前はフロントエンドモジュールと同じにするか、同じ名前を含める必要があります。例えば、フロントエンドモジュールの名前が
wknd-theme
の場合、そのモジュールを含むフォルダー名はwknd-theme-sources
のようになります。 - Cloud Manager フロントエンドパイプラインの名前には、フロントエンドモジュールの名前も含め、デプロイ先の環境(実稼動または開発)を追加する必要があります。 例えば、
wknd-theme
という名前のフロントエンドモジュールの場合、パイプラインにwknd-theme-prod
のような名前を付けることができます。
このような規則により、次のデプロイメントエラーを効率的に防ぐ必要があります。
- フロントエンドモジュールを間違ったサイトに適用する
- 同じサイトを適用する複数のフロントエンドモジュールを作成すると、相互に上書きされる
- 同じソースに対して複数のフロントエンドパイプラインを作成すると、競合状態が発生する可能性があり、デプロイメントの順序は保証されない
関心の分離 separation-of-concerns
関心の分離に適用されるもう 1 つのベストプラクティスは、関心を分離する契約の設計と管理の方法を特に注意することです。 フロントエンドパイプラインの場合、そのコードを他のコードと分離する契約は、サイトによってレンダリングされる HTML と JSON です。その HTML と JSON が安定した状態を維持した場合、フロントエンドパイプラインは、フロントエンドチームを完全に独立させることで、最大限の価値を提供します。
現在、フロントエンドパイプラインと同期してフルスタックパイプラインを実行する特定の機能はありません。このため、フロントエンド開発をフルスタックパイプラインから分離する場合は、これら 2 つの関心領域を分離する契約に細心の注意を払う必要があります。この契約は、通常、Experience Manager がレンダリングする HTML や JSON です。 したがって、異なるパイプラインを操作するチーム間で、対応する変更のシーケンス化方法に同意するよう、その契約の変更を適切に計画する必要があります。
両方の関心に影響を与える HTML や JSON 出力を変更する必要がある場合は、通常、次の手順をお勧めします。
-
バックエンドチームは、まず、新しい HTML や JSON 出力を使用して開発環境を設定します。
-
フルスタックパイプラインを介して、必要な新しい HTML や JSON 出力のレンダリングに必要なコードをデプロイします。
-
フロントエンドチームが以前にアクセス権を持っていなかった環境の場合は、次の手順を実行する必要があります。
- URL:フロントエンドチームは、その開発環境の URL を知っておく必要があります。
- ACL:フロントエンドチームには、「寄稿者」権限と似た権限を持つローカル AEM ユーザーが割り当てられている必要があります。
- Git:フロントエンドチームには、その開発環境を具体的にターゲットとするフロントエンドモジュール用として、個別の Git の場所が必要です。
- 通常は、
dev
分岐を作成します。これにより、開発環境で行われた変更を、実稼動環境にデプロイするmain
分岐に簡単にマージして戻すことができます。
- 通常は、
- パイプライン:フロントエンドチームには、開発環境にデプロイする、フロントエンドパイプラインが必要です。そのパイプラインは、前のポイントで説明したように、通常は
dev
分岐にあるフロントエンドモジュールをデプロイします。
-
-
次に、フロントエンドチームは、古い出力と新しい出力の両方で CSS と JS コードを動作するようにします。
-
通常どおり、ローカルで開発するには、次の手順を実行します。
- フロントエンドモジュール内で実行される
npx aem-site-theme-builder proxy
コマンドは、AEM 環境からコンテンツを要求するプロキシサーバーを起動し、フロントエンドモジュールの CSS ファイルと JS ファイルをローカルdist
フォルダーのファイルに置き換えます。 - 非表示の
.env
ファイルでAEM_URL
変数を設定すると、ローカルプロキシサーバーがコンテンツを使用する AEM 環境を制御できます。 - そのため、この
AEM_URL
の値を変更すると、両方の環境に適合するように CSS と JS を調整するために、実稼動環境と開発環境を切り替えることができます。 - 新しい出力をレンダリングする開発環境と、古い出力をレンダリングする実稼動環境で動作する必要があります。
- フロントエンドモジュール内で実行される
-
フロントエンドの作業は、更新されたフロントエンドモジュールが両方の環境で動作し、両方にデプロイされた時点で完了します。
-
-
その後、バックエンドチームは、フルスタックパイプラインを介して新しい HTML や JSON 出力をレンダリングするコードをデプロイすることにより、実稼動環境を更新できます。
-
次に、フロントエンドチームは、CSS と JS をクリーンアップして、古い出力でのみ必要だった内容を削除し、フロントエンドパイプラインを介して最後の更新を実稼動環境にデプロイできます。
その他のリソース additional-resources
- サイトテーマ - AEM サイトテーマを使用して、サイトのスタイルやデザインをカスタマイズする方法を説明します。
- AEM Site Theme Builder - アドビは、新しいサイトテーマを作成するための一連のスクリプトとして AEM Site Theme Builder を提供します。