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

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

はじめに

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

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

Cloud Manager には、顧客が素早くオンボーディングできるように、デジタルエクスペリエンスの開発を開始するために必要なものすべてが用意されています。カスタマイズ内容を保存する Git リポジトリも用意されており、Cloud Manager で構築、検証、デプロイを行うことができます。

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

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

• 開発
• ステージ
• 実稼動

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

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

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

Cloud Manager は、企業のニーズに合わせて調整できる、柔軟なマルチチーム設定をサポートしています。複数のチームで安定したデプロイメントを実現し、1 つのチームがすべてのチームの実稼動環境に影響を与えることを避けるために、Cloud Manager の固有パイプラインは常にすべてのチームのコードを同時に検証し、テストします。

実際の例

各企業には、チームの設定、プロセス、開発ワークフローなどで、異なる設定や要件があります。以下で説明する設定は、アドビが AEM as a Cloud Service をベースにエクスペリエンスを提供するいくつかのプロジェクトで使用されています。

例えば、Adobe Photoshop や Adobe Illustrator などの Adobe Creative Cloud アプリケーションには、エンドユーザーが使用できるチュートリアル、例、ガイドなどのコンテンツリソースが含まれています。このコンテンツは、AEM Cloud のパブリッシュ層に対して API 呼び出しを実行して構造化コンテンツを JSON ストリームとして取得し、 AEM as a Cloud Serviceのコンテンツ配信ネットワーク (CDN) 構造化コンテンツと非構造化コンテンツの両方を最適なパフォーマンスで提供する。

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

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

新しいプロジェクトをオンボーディングするには、共有 Git リポジトリーのルートにあるリアクター Maven プロジェクトファイルをリストする必要があります。ディスパッチャー設定の場合、新しい設定ファイルがディスパッチャープロジェクト内に作成されます。このファイルは、メインのディスパッチャー設定によってインクルードされます。各チームは、それぞれのディスパッチャー設定ファイルを管理します。共有 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 を使用すると、ローカルのオーサー、パブリッシャー、ディスパッチャーを設定できます。これにより、オフラインでの開発が可能になり、短時間での開発が可能となります。開発にはオーサー環境のみを使用する場合もありますが、ディスパッチャーとパブリッシャー環境を設定することで、Git リポジトリにプッシュする前に、すべてをローカルでテストできます。

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

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

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

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

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

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