AEM as a Cloud Service 向けのエンタープライズ開発チームのセットアップ enterprise-setup

エンタープライズ開発チームをセットアップして拡張する方法と、AEM as a Cloud Service（Adobe Experience Manager）が開発プロセスをサポートする方法について説明します。

はじめに introduction

エンタープライズ開発のセットアップを行うお客様をサポートするために、AEM as a Cloud Service は Cloud Manager およびその専用の固有 CI／CD パイプラインと完全に統合されています。 これらのパイプラインとサービスは、ベストプラクティスに基づいて構築されており、徹底的なテストと最高のコード品質を実現します。

エンタープライズチーム開発の設定での Cloud Manager のサポート cloud-manager

Cloud Managerでは、迅速なオンボーディングを実現するために、カスタマイズを保存するGit リポジトリなど、デジタルエクスペリエンスの開発に必要なあらゆる機能を提供しています。 これらのカスタマイズはCloud Managerで構築、検証、デプロイされます。

開発部門は、Cloud Managerを利用することで、Adobe担当者の支援なしに頻繁に変更を加えることができます。

Cloud Manager では、3 つのタイプの環境を使用できます。

コードは、実稼動以外のパイプラインを使用して開発環境にデプロイできます。 ステージング環境と本番環境は常に連携しているので、ベストプラクティスとして本番の前に検証を確実に実施できます。本番パイプラインでは、品質ゲートを使用してアプリケーションのコードと設定の変更を検証します。

実稼動パイプラインは、最初にコードと設定をステージング環境にデプロイし、それからアプリケーションをテストして、最後に実稼動環境にデプロイします。

常に最新のAEM as a Cloud Serviceの機能強化で更新されるCloud Service SDKを使用すると、開発者のローカルハードウェアを使用して直接ローカル開発できます。 このアプローチにより、リードタイムの短い迅速な開発が可能になります。 したがって、デベロッパーは慣れ親しんだローカル環境で様々な開発ツールを選択し、必要に応じて適切な開発環境や実稼動環境にプッシュすることができます。

Cloud Manager は、企業のニーズに合わせて調整できる、柔軟なマルチチーム設定をサポートしています。 複数のチームにわたって安定したデプロイメントを確実に行うには、Cloud Manager の固有パイプラインはすべてのチームのコードを同時に検証し、テストします。 このアプローチは、1 つのチームの変更がすべてのチームの実稼動に影響を与える状況を防ぐのに役立ちます。

シナリオの例 example-scenario

各企業には、チームの設定、プロセス、開発ワークフローなどで、異なる設定や要件があります。 Adobeでは、AEM as a Cloud Service上でエクスペリエンスを提供する複数のプロジェクトに対して、以下で説明する設定を使用します。

たとえば、Adobe PhotoshopやAdobe IllustratorなどのAdobe Creative Cloudアプリケーションには、チュートリアル、サンプル、ガイドなどのコンテンツリソースが含まれています。 クライアントアプリケーションは、ヘッドレスな方法で AEM as a Cloud Service のコンテンツを使用します。 構造化コンテンツを JSON ストリームとして取得するために、AEM Cloud パブリッシュ層への API 呼び出しを行います。 さらに、AEM as a Cloud Service のコンテンツ配信ネットワーク（CDN）を使用して、構造化コンテンツと非構造化コンテンツの両方を最適なパフォーマンスで提供します。

このプロジェクトに貢献するチームは、次のプロセスに従います。

各チームは独自の開発ワークフローを使用し、個別の Git リポジトリを持ちます。 追加の共有 Git リポジトリは、プロジェクトのオンボーディングに使用されます。 この Git リポジトリには、共通の Dispatcher 設定など、Cloud Manager の Git リポジトリのルート構造が含まれています。

新しいプロジェクトをオンボーディングするには、共有Git リポジトリのルートにあるreactor Maven プロジェクトファイルにリストが必要です。 Dispatcher 設定の場合、新しい設定ファイルが Dispatcher プロジェクト内に作成されます。 メインの Dispatcher 設定にはこのファイルが含まれます。 各チームは、それぞれの Dispatcher 設定ファイルを管理します。 共有Git リポジトリへの変更はまれであり、新しいプロジェクトがオンボーディングされたときにのみ必要です。 各プロジェクトチームは、独自のGit リポジトリ内で主要な作業を実行します。

各チームのGit リポジトリは、AEM プロジェクトアーキタイプ ​を使用して設定されるので、AEM プロジェクトの設定に関するベストプラクティスに従います。 唯一の例外は、上述のように共有 Git リポジトリで実行される Dispatcher 設定です。

各チームは、Git フローモデルに従って、2 + N の分岐があるシンプルな Git ワークフローを使用します。

開発は機能分岐で行われます。 機能が成熟すると、開発ブランチに結合されます。 完了および検証済みの機能は、開発ランチから選択され、安定ランチに結合されます。

すべての変更は、プルリクエスト（PR）を通じて行われます。 品質ゲートは、各 PR を自動的に検証します。 Sonar はコードの品質チェックに使用され、一連のテストスイートを実行して、新しいコードが回帰を起こさないことを確認します。

Cloud Manager の Git リポジトリの設定には、次の 2 つのブランチがあります。

開発または安定ブランチでのチームの Git リポジトリに対するすべてのプッシュが、GitHub アクションをトリガーします。

安定ブランチについては、すべてのプロジェクトが同じ設定に従います。 プロジェクトの安定ブランチへのプッシュは、Cloud Manager の Git リポジトリの安定ブランチに自動的にプッシュされます。 安定ブランチへのプッシュは、Cloud Manager の実稼動パイプラインをトリガーします。 安定したブランチにチームがプッシュするたびに、実稼動パイプラインがトリガーされます。 すべての品質ゲートを通過すると、実稼動デプロイメントが更新されます。

開発分岐へのプッシュの処理は異なります。 チームのGit リポジトリ内のdevelopment ブランチへのプッシュでも、GitHub アクションがトリガーされます。 このアクションにより、コードが Cloud Manager の Git リポジトリの開発ブランチに自動的にプッシュされます。 ただし、このコードプッシュで、実稼動以外のパイプラインが自動的にトリガーされることはありません。 Cloud Manager の API を呼び出すと、トリガーされます。

実稼動パイプラインの実行には、提供された品質ゲートを介して、すべてのチームのコードをチェックすることが含まれます。 コードがステージにデプロイされると、テストと監査が実行され、すべてが想定どおりに動作します。 すべてのゲートを通過すると、変更は中断やダウンタイムなしで実稼動環境にロールアウトされます。

ローカル開発の場合は、AEM as a Cloud Service 用の SDK が使用されます。 SDK を使用すると、ローカルのオーサー、パブリッシャー、Dispatcher を設定できます。 このワークフローにより、オフライン開発とリードタイムの短縮が可能になります。 開発にはオーサー環境のみを使用する場合もありますが、Dispatcher とパブリッシャー環境をすばやく設定すれば、Git リポジトリにプッシュする前に、すべてをローカルでテストできます。

各チームのメンバーは通常、共有Gitからコードをチェックアウトして、自分のプロジェクトコードを確認します。 プロジェクトは独立しているので、他のプロジェクトをチェックアウトする必要はありません。

この設定は、参照として使用し、企業のニーズに合わせてカスタマイズできます。 Git のブランチとマージの概念は柔軟性が高く、上記のワークフローを様々なチームのニーズに合わせてカスタマイズできます。 AEM as a Cloud Service は、専用の Cloud Manager パイプラインのコアバリューを犠牲にすることなく、これらすべてのバリエーションをサポートします。

マルチチームセットアップの考慮事項 considerations

Cloud Manager の Git リポジトリと実稼動パイプラインでは、完全な実稼動コードは、常にすべての品質ゲートを通過し、1 つのデプロイメントユニットとして扱われます。 これにより、本番システムは中断やダウンタイムなしで常に利用可能になります。

これに対し、このようなシステムがない場合は、各チームが個別にデプロイできるので、あるチームのアップデートが実稼動の安定性の問題につながるリスクがあります。 さらに、アップデートをロールアウトするには、調整と計画的なダウンタイムが必要です。 チーム数が増えるにつれ、調整作業はより複雑になり、すぐに管理不可能になります。

また、品質ゲートで問題が検出された場合も生産環境に影響はなく、Adobeのスタッフが介入することなく問題を検出して修正することができます。 AEM as a Cloud Serviceを使用せず、デプロイメント全体を常にテストしない場合、部分的なデプロイメントでは、ロールバック要求やバックアップからの完全な復元を必要とする停止が発生する可能性があります。 部分的なテストでは、後で解決する必要がある問題が発生する場合もあり、Adobeスタッフの調整とサポートが必要です。