Learn how Adobe Experience Manager (AEM) as a Cloud Service uses continuous integration and delivery (CI/CD) to keep your projects on the latest version.
AEM as a Cloud Service uses continuous integration and continuous delivery (CI/CD) to ensure that your projects are on the most current AEM version. This process seamlessly updates your production, staging, and development instances without causing any disruption to your users.
Before your instances are automatically updated, a new AEM Maintenance release is published 3-5 days in advance. During this period, you can optionally trigger manual updates for your development instances. After this time elapses, version updates are automatically applied to your development environments first. If the update is successful, the update process proceeds to your stage and production instances. The development and staging instances act as an automated quality gate, where your custom-written tests are run before the update is applied on your production environment.
Note: The automatic updates for development environments are progressively enabled in 2023 for all customers. If your development environments are not automatically updated, you can use manual updates to keep them in sync with your stage and production environments.
There are two types of AEM version updates:
Check key dates for monthly releases on the Experience Manager releases roadmap and mark your calendars to prepare yourself for the key activities to get ready for the release.
AEM updates go through an intense and fully automated product validation pipeline involving multiple steps, ensuring no disruption of service for any systems in production. Health checks are used to monitor the health of the application. If these checks fail during an AEM as a Cloud Service update, the release does not proceed, and Adobe investigates why the update caused this unexpected behavior.
When you deploy a new version of custom code on your environment, Product and Custom functional tests play a crucial role. They ensure that the production systems remain stable and functional even after a change is applied. These tests are also applied in the AEM Version update process.
If the update to the production environment fails, Cloud Manager automatically rolls back the staging environment. This is done automatically to make sure that after an update completes, both the staging and production environments are on the same AEM version.
Similarly, if an automated update of a development environment fails, staging and production environments are not updated.
If custom code was pushed to staging and not to production, the next AEM update removes those changes to reflect the git tag of the last successful customer release to production. Therefore, the custom code that was only available on staging must be deployed again.
Stage Environment Usage
Production Pipeline
Non-Production Pipeline
Content Copy
Automated Functional Testing
If you encounter an issue related to regression, submit a support case by way of the Admin Console. If the issue is a blocker and its impacting Production, a P1 should be raised. Provide all details required to reproduce the regression issue.
Usually, updates incur zero downtime, including for the authoring instance, which is a cluster of nodes. Rolling updates are possible due to the composite node store feature in Oak.
This feature allows AEM to reference multiple repositories simultaneously. In a rolling deployment, the new AEM version contains its own /libs
(the TarMK based immutable repository). It is distinct from the older AEM version, although both reference a shared DocumentMK based mutable repository that contains areas like /content
, /conf
, /etc
and others.
Because both the old and the new versions have their own versions of /libs
, they can both be active during the rolling update. And, both can take on traffic until the old is fully replaced by the new.