フロントエンドパイプラインを使用したサイトの開発

フロントエンドパイプラインを使用すると、 フロントエンド開発者の自主性が高まり、開発プロセスを大幅に加速できます。このドキュメントでは、このプロセスの可能性を最大限に活かすために、このプロセスがどのように機能するかと、注意が必要な考慮事項を説明します。

ヒント

フロントエンドパイプラインの使用方法とそれによるメリットをまだ習熟していない場合は、 クイックサイト作成ジャーニー を参照して、新しいサイトをすばやくデプロイし、そのテーマをバックエンド開発と完全に切り離してカスタマイズする方法の例を確認してください。

フロントエンドビルドコントラクト

フルスタックビルド環境と同様に、フロントエンドパイプラインには独自の環境があります。次のフロントエンドビルドコントラクトが守られている限り、開発者はこのパイプラインにある程度の柔軟性があります。

フロントエンドパイプラインでは、フロントエンド Node.js プロジェクトで build スクリプトディレクティブを使用して、フロントエンドパイプラインによってデプロイされるビルドを生成する必要があります。つまり Cloud Manager はコマンド npm run build を使用して、デプロイ可能なプロジェクトを dist フォルダーに生成します。

dist フォルダーのコンテンツは、最終的に Cloud Manager パイプラインから AEM as a Cloud Service にデプロイされるものです。

ノードのバージョン

デフォルトでは、フロントエンドパイプラインはノード 14 を使用しますが、12 と 16 も使用できます。

CM_CUSTOM_VAR_NODE_VERSION 環境変数を使用して、目的のバージョンを設定できます。

唯一の情報源

一般的なベストプラクティスは、AEM に何がデプロイされているかに対する、唯一の情報源を維持することです。Cloud Manager の目的は、その唯一の情報源を明確にすることです。ただし、フロントエンドパイプラインではコードの一部の場所を分離できるため、フロントエンドパイプラインを正しく設定する必要が出ます。同じ環境の同じサイトにデプロイするフロントエンドパイプラインを複数作成しないように注意する必要があります。

このため、特に複数のフロントエンドパイプラインを作成する場合は、次のような体系的な命名規則を維持することをお勧めします。

  • package.json ファイルの name プロパティで定義されるフロントエンドモジュールの名前には、適用先のサイトの名前を含める必要があります。例えば、/content/wknd の場所にあるサイトの場合、フロントエンドモジュールの名前は wknd-theme のようになります。
  • フロントエンドモジュールが他のモジュールと同じ Git リポジトリを共有する場合、そのフォルダーの名前はフロントエンドモジュールと同じにするか、同じ名前を含める必要があります。例えば、フロントエンドモジュールの名前が wknd-theme の場合、そのモジュールを含むフォルダー名は wknd-theme-sources のようになります。
  • Cloud Manager フロントエンドパイプラインの名前には、フロントエンドモジュールの名前も含め、デプロイ先の環境（実稼動または開発）を追加する必要があります。 例えば、wknd-theme という名前のフロントエンドモジュールの場合、パイプラインに wknd-theme-prod のような名前を付けることができます。

このような規則により、次のデプロイメントエラーを効率的に防ぐ必要があります。

  • フロントエンドモジュールを間違ったサイトに適用する
  • 同じサイトを適用する複数のフロントエンドモジュールを作成すると、相互に上書きされる
  • 同じソースに対して複数のフロントエンドパイプラインを作成すると、競合状態が発生する可能性があり、デプロイメントの順序は保証されない

関心の分離

関心の分離に適用されるもう 1 つのベストプラクティスは、関心を分離する契約の設計と管理の方法を特に注意することです。 フロントエンドパイプラインの場合、そのコードを他のコードと分離する契約は、サイトによってレンダリングされる HTML と JSON です。その HTML と JSON が安定した状態を維持した場合、フロントエンドパイプラインは、フロントエンドチームを完全に独立させることで、最大限の価値を提供します。

現在、フロントエンドパイプラインと同期してフルスタックパイプラインを実行する特定の機能はありません。このため、フロントエンド開発をフルスタックパイプラインから分離する場合は、これら 2 つの関心領域を分離する契約に細心の注意を払う必要があります。この契約は、通常、Experience Manager がレンダリングする HTML や JSON です。 したがって、異なるパイプラインを操作するチーム間で、対応する変更のシーケンス化方法に同意するよう、その契約の変更を適切に計画する必要があります。

両方の関心に影響を与える HTML や JSON 出力を変更する必要がある場合は、通常、次の手順をお勧めします。

  1. バックエンドチームは、まず、新しい HTML や JSON 出力を使用して開発環境を設定します。
    1. フルスタックパイプラインを介して、必要な新しい HTML や JSON 出力のレンダリングに必要なコードをデプロイします。
    2. フロントエンドチームが以前にアクセス権を持っていなかった環境の場合は、次の手順を実行する必要があります。
      1. URL：フロントエンドチームは、その開発環境の URL を知っておく必要があります。
      2. ACL：フロントエンドチームには、「寄稿者」権限と似た権限を持つローカル AEM ユーザーが割り当てられている必要があります。
      3. Git：フロントエンドチームには、その開発環境を具体的にターゲットとするフロントエンドモジュール用として、個別の Git の場所が必要です。
        • 通常は、dev 分岐を作成します。これにより、開発環境で行われた変更を、実稼動環境にデプロイする main 分岐に簡単にマージして戻すことができます。
      4. パイプライン：フロントエンドチームには、開発環境にデプロイする、フロントエンドパイプラインが必要です。そのパイプラインは、前のポイントで説明したように、通常は dev 分岐にあるフロントエンドモジュールをデプロイします。
  2. 次に、フロントエンドチームは、古い出力と新しい出力の両方で CSS と JS コードを動作するようにします。
    1. 通常どおり、ローカルで開発するには、次の手順を実行します。
      1. フロントエンドモジュール内で実行される npx aem-site-theme-builder proxy コマンドは、AEM 環境からコンテンツを要求するプロキシサーバーを起動し、フロントエンドモジュールの CSS ファイルと JS ファイルをローカル dist フォルダーのファイルに置き換えます。
      2. 非表示の .env ファイルで AEM_URL 変数を設定すると、ローカルプロキシサーバーがコンテンツを使用する AEM 環境を制御できます。
      3. そのため、この AEM_URL の値を変更すると、両方の環境に適合するように CSS と JS を調整するために、実稼動環境と開発環境を切り替えることができます。
      4. 新しい出力をレンダリングする開発環境と、古い出力をレンダリングする実稼動環境で動作する必要があります。
    2. フロントエンドの作業は、更新されたフロントエンドモジュールが両方の環境で動作し、両方にデプロイされた時点で完了します。
  3. その後、バックエンドチームは、フルスタックパイプラインを介して新しい HTML や JSON 出力をレンダリングするコードをデプロイすることにより、実稼動環境を更新できます。
  4. 次に、フロントエンドチームは、CSS と JS をクリーンアップして、古い出力でのみ必要だった内容を削除し、フロントエンドパイプラインを介して最後の更新を実稼動環境にデプロイできます。

その他のリソース

  • サイトテーマ - AEM サイトテーマを使用して、サイトのスタイルやデザインをカスタマイズする方法を説明します。
  • AEM Site Theme Builder - アドビは、新しいサイトテーマを作成するための一連のスクリプトとして AEM Site Theme Builder を提供します。

このページ