AEM as a Cloud Service向けエンタープライズ開発チームの設定

エンタープライズ開発チームを設定および拡張する方法と、AEMas a Cloud Serviceが開発プロセスをサポートする方法を確認します。

はじめに

エンタープライズ開発の設定でのお客様をサポートするために、AEM as a Cloud Serviceは Cloud Manager と完全に統合され、その目的に基づいて構築されています。 独自の CI/CD パイプライン。 これらのパイプラインとサービスは、ベストプラクティスに基づいて構築され、徹底的に テストと最高のコード品質。

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

迅速なオンボーディングを確実におこなうために、Cloud Manager は、カスタマイズを保存し、Cloud Manager で構築、検証、デプロイする Git リポジトリなど、デジタルエクスペリエンスの開発をすぐに開始するために必要なすべてを提供します。

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

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

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

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

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

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

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

実際の例

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

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

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

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

新しいプロジェクトをオンボーディングするには、共有 Git リポジトリーのルートにあるリアクター Maven プロジェクトファイルをリストする必要があります。ディスパッチャー設定の場合、新しい設定ファイルがディスパッチャープロジェクト内に作成されます。このファイルは、メインのディスパッチャー設定によってインクルードされます。各チームは、それぞれのディスパッチャー設定ファイルを管理します。共有 Git リポジトリーの変更はほとんど行われず、通常は新しいプロジェクトをオンボードする場合にのみ必要です。主な作業は、各プロジェクトチームがそれぞれの Git リポジトリー内で行います。

それぞれの Git リポジトリは、 AEM Project Archetype そのため、AEMプロジェクトを設定する際のベストプラクティスに従います。 唯一の例外は、上述のように共有 Git リポジトリで実行される Dispatcher 設定です。

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

• 安定リリースブランチには、実稼動コードが含まれます.

• 開発ブランチには、最新の開発が含まれます.

• 各機能に対しては、新しいブランチが作成されます.

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

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

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

• 安定したリリースブランチには、すべてのチームの実稼動用コードが含まれています。
• 開発ブランチには、すべてのチームの開発コードが含まれます。

開発または安定したブランチのチームの Git リポジトリへのすべてのプッシュトリガーa 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 パイプラインのコアバリューを犠牲にすることなく、これらすべてのバリエーションをサポートします。

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

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

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

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

Business.Adobe.com リソース