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 を使用することによって、開発チームは、アドビの担当者に依存することなく、頻繁に変更をコミットできます。

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

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

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

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

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

実際の例 real-world-example

各企業には、チームの設定、プロセス、開発ワークフローなどで、異なる設定や要件があります。以下で説明する設定は、アドビが 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 リポジトリのルートにあるリアクター 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 リポジトリ内の開発ブランチへのプッシュは、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 つのデプロイメントユニットとして扱われます。このようにして、実稼動システムは中断やダウンタイムなしで常時稼動します。

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

品質ゲートで問題が検出された場合、実稼動に影響はなく、アドビの担当者が介入しなくても問題の検出と修正が可能です。Cloud Service を利用せず、デプロイメント全体の常時テストを行わないと、部分的なデプロイメントによってサービス停止が発生し、ロールバックや、バックアップからの完全な復元が必要となることもあります。部分的なテストでは、後で解決しなければならない問題が発生する可能性があり、やはりアドビ担当者との調整とサポートが必要になります。