Adobe Experience Manager(AEM)as a Cloud Serviceで継続的な統合および配信 (CI/CD) を使用して、プロジェクトを最新バージョンに保つ方法を説明します。
AEM as a Cloud Service では、継続的統合および継続的配信(CI/CD)を使用して、プロジェクトを確実に最新の AEM バージョンで稼働できます。このプロセスは、ユーザーに混乱を与えることなく、実稼動、ステージング、開発の各インスタンスをシームレスに更新します。
インスタンスが自動的に更新される前に、新しいAEMメンテナンスリリースが 3 ~ 5 日前に公開されています。 この期間中は、オプションで トリガーインスタンスの開発用の手動更新. この期間が経過すると、バージョンの更新が最初に開発環境に自動的に適用されます。 更新が成功すると、更新プロセスはステージインスタンスと実稼動インスタンスに進みます。 開発インスタンスとステージングインスタンスは、自動品質ゲートとして機能し、カスタムで作成されたテストは、実稼動環境にアップデートが適用される前に実行されます。
注意:開発環境の自動更新は、2023 年にすべてのお客様に対して段階的に有効になります。 開発環境が自動的に更新されない場合は、手動更新を使用して、ステージ環境および実稼動環境との同期を維持できます。
AEMバージョンのアップデートは、次の 2 種類があります。
の毎月のリリースの主な日付を確認します。 Experience Managerリリースロードマップ リリースの準備を整えるために、主要なアクティビティの準備をするために、カレンダーにマークを付けます。
AEM のアップデートは、複数のステップを含む集中的かつ完全に自動化された製品検証パイプラインを経て行われるため、実稼働環境にあるシステムへのサービスが中断されることはありません。ヘルスチェックは、アプリケーションのヘルスを監視するために使用されます。AEMのas a Cloud Serviceアップデート中にこれらのチェックが失敗した場合、リリースは続行されず、アップデートがこの予期しない動作を引き起こした原因をAdobeが調べます。
環境に新しいバージョンのカスタムコードをデプロイする場合、 製品およびカスタム機能テスト 重要な役割を果たす。 これにより、変更を加えた後でも、本番システムの安定性と機能性が確保されます。 これらのテストは、AEM Version Update プロセスでも適用されます。
実稼動環境への更新が失敗した場合、Cloud Manager はステージング環境を自動的にロールバックします。 これは、更新が完了した後で、ステージング環境と実稼動環境の両方が同じAEMバージョンであることを確認するために、自動的におこなわれます。
同様に、開発環境の自動更新が失敗した場合、ステージング環境と実稼動環境は更新されません。
カスタムコードがステージング環境にプッシュされ、実稼動環境にプッシュされなかった場合、次回のAEM更新でこれらの変更が削除され、顧客が前回実稼動環境に正常にリリースした際の git タグが反映されます。 したがって、ステージングでのみ使用可能なカスタムコードを再度デプロイする必要があります。
ステージ環境の使用状況
実稼動パイプライン
実稼動以外のパイプライン
コンテンツのコピー
自動機能テスト
回帰に関する問題が発生した場合は、Admin Consoleでサポートケースを送信します。 問題が致命的で、その影響が実稼動に及ぶ場合は、P1 を発生させる必要があります。 回帰の問題の再現に必要なすべての詳細を指定します。
通常、ノードのクラスターであるオーサリングインスタンスを含め、更新でダウンタイムは発生しません。 Oak の複合ノードストア機能により、ローリングアップデートが可能です。
この機能を利用すると、AEM で複数のリポジトリを同時に参照できます。内 ローリングデプロイメントの場合、新しいAEMバージョンには独自の /libs
(TarMK ベースの不変リポジトリ)。 古いAEMとは異なりますが、どちらも、次のような領域を含む共有 DocumentMK ベースの可変リポジトリを参照します /content
, /conf
, /etc
その他
古いバージョンと新しいバージョンの両方には、 /libs
に値を指定しない場合、両方をローリング更新時にアクティブにできます。また、古いが新しいに完全に置き換えられるまで、両方ともトラフィックを引き継ぐことができます。