AEM Version Updates

Learn how AEM as a Cloud Service uses continuous integration and delivery (CI/CD) in order to keep you projects on the latest version.

CI/CD

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 means that production and staging instances are updated to the latest AEM version without any interruption of service for users.

Version updates are applied automatically to production and staging instances only. AEM updates must be applied manually to all other instances.

Type of Updates

There are two types of AEM version updates:

  • AEM Maintenance Updates

    • Can be released on a daily basis.
    • Are mostly for maintenance purposes, including the latest bug-fixes and security updates.
    • Have minimal impact since changes are applied regularly.

  • New Feature Updates

Update Failure

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 will not proceed and Adobe will investigate why the update caused this unexpected behavior.

Product tests and Customer functional tests, which prevent product upgrades and customer code pushes from breaking production systems, are also validated during an AEM version update.

If the update to production environment fails, Cloud Manager will automatically roll back the staging environment. This is done automatically to make sure that after an update completes, both the staging and production environments are on same AEM version.

NOTE

If custom code was pushed to staging and not to production, the next AEM update will remove 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 will have to be deployed again.

Composite Node Store

Updates in most cases will 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 blue-green deployment, the new green AEM version contains its own /libs (the TarMK based immutable repository), distinct from the older blue AEM version, although both reference a shared DocumentMK based mutable repository that contains areas like /content , /conf , /etc and others.

Because both the blue and the green have their own versions of /libs, they can both be active during the rolling update, both taking on traffic until the blue is fully replaced by the green.

On this page