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

企業の開発チームの構築と拡張の方法について説明し、AEM（Adobe Experience Manager）のas a Cloud Serviceが開発プロセスをどのようにサポートできるかを説明します。

はじめに 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 プロジェクトの設定のベストプラクティスに従います。 唯一の例外はDispatcher設定です。これは、前述のように共有 Git リポジトリーで実行されます。

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

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

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

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

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

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

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

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

ローカル開発の場合は、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 を利用せず、デプロイメント全体の常時テストを行わないと、部分的なデプロイメントによってサービス停止が発生し、ロールバックや、バックアップからの完全な復元が必要となることもあります。部分的なテストを実施した場合も、後で解決しなければならない問題が発生する可能性があり、Adobe担当者との調整とサポートが必要になります。