AEM as aCloud Serviceのエンタープライズチーム開発設定

はじめに

AEM as a AEM as a serviceを提供するクラウドネイティブな製品であるCloud Service as aは、エンタープライズチームに対して、10年以上にわたるエンタープライズソフトウェアの提供を、それぞれ固有の要件に基づいて実現することを目的として設計されています。 AEMは、常にオン、常に最新、常に安全、常に拡張などの新しい価値を持つクラウドネイティブな世界に取り込まれますが、AEMはカスタマイズ可能なプラットフォームとして顧客に提供し、エンタープライズグレードのチームの開発と配信の手順で統合できます。

お客様にエンタープライズ開発の設定を提供するために、AEM as aCloud ServiceはCloud Managerと独自に開発したCI/CDパイプラインを完全に統合し、エンタープライズグレードの開発とデプロイメントの経験から得たベストプラクティスと学習を提供します。

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

顧客がすばやくオンボーディングできるように、Cloud Managerは、カスタマイズを保存し、Cloud Managerで構築、検証、デプロイするGitリポジトリなど、エクスペリエンスの開発をすぐに始めるのに必要なすべてを提供します。
開発チームは、Cloud Managerを使用して、変更担当者に依存することなく、頻繁に変更をコミットするように取り組むことができます。

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

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

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

実稼動パイプラインは、最初にコードと設定をステージング環境にデプロイし、アプリケーションをテストして、最後に実稼動環境にデプロイします。
常に最新のCloud Service機能強化で更新されるCloud ServiceSDKを使用すると、開発者のローカルハードウェアを直接利用したローカル開発が可能になります。 これにより、非常に短時間で迅速な開発が可能になります。 したがって、開発者は身近なローカル環境にとどまり、様々な開発ツールから選択し、適切な環境や実稼動環境にプッシュすることができます。

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

実際の例

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

例えば、Adobe PhotoshopやAdobe IllustratorなどのAdobe Creative Cloudアプリケーションには、エンドユーザーが使用できるチュートリアル、サンプル、ガイドなどのコンテンツリソースが含まれています。 このコンテンツは、AEMをCloud Serviceとして​ヘッドレス​方式で使用し、AEM Cloudのパブリッシュ層にAPI呼び出しを実行して構造化コンテンツをJSONストリームとして取得し、構造化コンテンツと非構造化コンテンツの両方を最適なCloud Service🔗としてAEMで利用します。

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

メモ

設定について詳しくは、複数のソースGitリポジトリーの操作を参照してください。

各チームは独自の開発ワークフローを使用し、個別のGitリポジトリを持ちます。 追加の共有Gitリポジトリは、プロジェクトのオンボーディングに使用されます。 このGitリポジトリには、共有Dispatcher設定を含むCloud ManagerのGitリポジトリのルート構造が含まれています。 新しいプロジェクトをオンボーディングするには、共有GitリポジトリのルートにあるリアクターMavenプロジェクトファイルをリストする必要があります。 Dispatcher設定の場合、新しい設定ファイルがDispatcherプロジェクト内に作成されます。 このファイルは、メインのDispatcher設定によってインクルードされます。 各チームは、独自のDispatcher設定ファイルを管理します。 共有Gitリポジトリの変更はまれにおこなわれ、通常は新しいプロジェクトをオンボードする場合にのみ必要です。 主な作業は、各プロジェクトチームが独自のGitリポジトリ内でおこないます。

各チームのGitリポジトリは、AEM Mavenアーキタイプを使用して設定されているので、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 aCloud Service用のSDKが使用されます。 SDKを使用すると、ローカルのオーサー、パブリッシュ、ディスパッチャーを設定できます。 これにより、オフラインでの開発と迅速なターンアウトが可能になります。 作成者のみが開発に使用される場合もありますが、Dispatcherとパブリッシュをすばやく設定すると、Gitリポジトリにプッシュする前に、すべてをローカルでテストできます。 各チームのメンバーは、通常、の共有Gitおよび独自のプロジェクトコードからコードをチェックアウトします。 プロジェクトは独立しているので、他のプロジェクトをチェックアウトする必要はありません。

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

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

メモ

マルチチームのセットアップでは、ガバナンスモデルと一連の標準を定義することが重要です。すべてのチームが従う必要があります。 上記のマルチチームセットアップのブループリントの概要では、多数のチームを対象にスケールを設定でき、このブループリントを出発点として使用できます。

Cloud ManagerのGitリポジトリと実稼動パイプラインでは、常に完全な実稼動コードはすべての品質ゲートを通じて実行され、1つのデプロイメントユニットとして扱われます。 このようにして、本番システムは​常にに中断やダウンタイムなしで稼働し続けます。
これに対し、このようなシステムがない場合は、各チームが個別に導入できるので、1つのチームからの更新が生産の安定性の問題につながるリスクがあります。 さらに、更新を展開するには、調整と計画的なダウンタイムが必要です。 チーム数が増えるにつれ、調整作業はより複雑になり、迅速に管理できなくなります。

品質ゲートで問題が検出された場合、生産に影響はなく、問題の検出と修正が可能です。Adobe担当者が介入する必要はありません。 Cloud Serviceがなく、常に導入全体をテストしなくても、部分的な導入は、バックアップからの完全な復元を要求する必要がある停止を引き起こす可能性があります。 部分的なテストは、他の問題にもつながる可能性がありますが、再びAdobe担当者の調整とサポートが必要になった後で修正する必要があります。

このページ