Cloud ServiceとしてのAEM用エンタープライズチーム開発セットアップ

概要

AEMをCloud Serviceとして提供するクラウドネイティブ製品は、AEMをサービスとして提供する製品です。10年以上にわたり、企業の各チームに対して、それぞれ固有の要件を満たして提供してきたというメリットを享受できるように設計されています。 AEMは、常にon、always urrent、always secure、always scaleといった新しい値を持つクラウドネイティブの世界に導入されますが、AEMがカスタマイズ可能なプラットフォームとしてお客様に提供する主な価値提案を維持し、配信や開発の手順にエンタープライズグレードチームを統合できます。

企業開発の設定をサポートするため、AEMはCloud Managerと独自に開発したCI/CDパイプラインと完全に統合できます。CI/CDパイプラインは、企業グレードの開発と導入に関する複数年の経験から学び、徹底したテストと最高のコード品質を確保します。

エンタープライズチーム開発セットアップでのCloud Managerのサポート

Cloud Managerは、顧客に対して迅速なオンボーディングを実現するために、エクスペリエンスの開発をすぐに始めるために必要なすべてを提供します。Gitリポジトリには、カスタマイズを保存し、Cloud Managerで構築、検証および展開できます。
開発チームは、Cloud Managerを使用して、Adobeの担当者に依存することなく、頻繁に変更をコミットする作業を行うことができます。

Cloud Managerでは、次の3種類の環境を使用できます。

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

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

実稼働パイプラインは、まずコードと設定をステージング環境にデプロイし、テストして実稼働環境にデプロイします。
Cloud ServiceSDKは、常に最新のCloud Serviceの機能強化を反映してアップデートされ、開発者のローカルハードウェアを直接利用してローカルで開発できます。 これにより、非常に短い回転時間での迅速な開発が可能になります。 開発者は身近なローカル環境にとどまり、様々な開発ツールから選択でき、適切な開発環境や制作を行うことができます。

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ストリームとして取得し、AEMのContent Network(CDN)をCloud Serviceとして活用し、最適なパフォーマンスです。

このプロジェクトに貢献するチームは、以下の手順に従います。

メモ

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

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

各チームのgitリポジトリは、AEM Mavenアーキタイプを使用して設定され、AEMプロジェクトの設定のベストプラクティスに従っています。 唯一の例外は、上で説明したように共有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 Managerのapiへの呼び出しによってトリガーされます。
実稼働パイプラインの実行には、提供された品質ゲートを介してすべてのチームのコードをチェックすることも含まれます。 コードがステージにデプロイされると、テストと監査が実行され、すべてが期待どおりに動作することが確認されます。 すべてのゲートが通過すると、変更は中断やダウンタイムを発生させることなく、本番環境に展開されます。
ローカル開発では、Cloud ServiceとしてのAEM用SDKが使用されます。 SDKを使用すると、ローカルの作成者、発行、およびディスパッチャーを設定できます。 これにより、オフラインでの開発と迅速な再開が可能になります。 開発にはauthorしか使用されない場合もありますが、ディスパッチャーと発行をすばやく設定すると、gitリポジトリにプッシュする前にすべてをローカルでテストできます。 各チームのメンバーは、通常、の共有gitからコードおよび独自のプロジェクトコードをチェックアウトします。 プロジェクトは独立しているので、他のプロジェクトをチェックアウトする必要はありません。

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

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

メモ

複数のチームを組み合わせる場合は、管理モデルと一連の標準を定義することが重要です。すべてのチームが従う必要があります。 上述のマルチチームの設定の設計図は、多数のチームを対象にスケーリングを可能にし、この設計図を出発点として使用できます。

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

クォリティゲートで問題が検出された場合、生産に影響が出ず、Adobeの作業員が入室する必要なく、問題を検出して修正することができます。 Cloud Serviceがなく、必ず導入全体をテストする必要もなく、部分的な導入を行うと、バックアップからのロールバック要求や完全なリストアを必要とする停止が発生する場合があります。 部分的なテストは、他の問題も引き起こす可能性があります。Adobeの担当者が再度調整とサポートを必要とした後で、修正する必要があります。

このページ

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now