Continuous Delivery on Adobe AEM

I get asked a lot what I think about various topics on Adobe AEM. Many large companies are now attempting to implement a solution on Adobe AEM, and Continuous Delivery is one of the topics that keeps coming up. Unlike many typical features of AEM, there is not much guidance in the documentation about how to implement Continuous Delivery yet I believe AEM is very much suitable for it. So I wanted to share my thoughts on this topic hoping it might help someone in their implementation of AEM.

What is Continuous Delivery?
I understand Continuous Delivery as an IT process of continuously releasing pieces of content or functionality, from inception at a whiteboard to release to production, without downtime, often fully automated. This is in contrast to the typical enterprise IT process that requires many manual steps, the involvement of many people, and a typical release cycle of one to two weeks.

Continuous Delivery is often associated with an Agile development process, as it allows us to deliver small pieces of production quality functionality, frequently. And I don't just mean iterative delivery such as in fortnightly iterations, but multiple releases per day.

These additional requirements on the IT processes - frequency, quality, no downtime - also spread beyond the processes, on the architecture, IT infrastructure, development processes and tooling, quality processes, and company culture.

Continuous Delivery on Adobe AEM

The architecture of Adobe AEM as the platform leverages itself particularly well to Continuous Delivery because of OSGi and JCR.

OSGi modularity
OSGi allows the development and deployment of individual modules (bundles). OSGi is an SOA within a single Java process, and it allows you to be as granular with your deployment units as you need. You can go Micro Services, deploying individual service implementations at once, or bundle the whole subsystem. But either way, you get a straightforward (almost) no-downtime deployment mechanism via bundles, which also supports easy rollback.

Flexible modularity also means the ability to develop functionality independently so your developers can work on multiple work streams in parallel. And because you can deploy as big or as small units as you need, it works well with Agile development processes where the scope of a deployable task could be a single component or a service.

Deploying to JCR
In Adobe AEM, JCR typically stores the components, templates, and front-end artifacts in the form of objects with metadata, and these are deployed via packages. The neat thing about those is that they are typically static files or scripts, plus metadata, which doesn't require any restart. So they come into effect immediately after being updated, and you can update any piece of JCR at any time - whether it is one component, or the whole website (called Projects in AEM) - and it takes milliseconds to seconds. As the result, you can continuously evolve JCR, on the fly, without any downtime, deploying multiple features in parallel to production. And to mitigate the risks, simple rollback mechanisms such as deploying the previous version of a package, or creating a reverse package, can be used.

Because AEM architecture is so simple - a single application component is a single instance and a single Java process, in non-clustered cases the deployment only touches a single instance. Apart from caching, very little can go out-of-sync or wrong - the artifacts are either in JCR and active, or they are not. Even in clustering scenarios, the deployment to a cluster of production Publish instance (the riskiest scenario) is often done via replication which is aware of clustering and ensures all Publish instances are in sync.

Feature switches
Feature switches are a mechanism that allows instantaneous change of system behavior without redeployment. Typically Feature switches are used to control risky or incomplete features, and for a/b testing of functionality, and because of that they can be used to reduce the risks of deploying features at a rapid pace.

Consider the scenario when during a day, 5 features were implemented and deployed by different developers. 4 of them work fine, and 1 does not work. If you were to deal with the situation in a typical source-controlled environment, you'd have to make a reverse commit for the broken commit, test and redeploy. But with Feature switches, you can simply disable the broken functionality until the time when it's fixed.

Feature switches can be implemented on both OSGi service properties and JCR properties as they can be controlled by HTTP requests.

Caching
Caching is the only thing that requires careful planning and sometimes additional work. As Adobe AEM is designed to be heavily cached (the guideline is 90%), any changes to underlying resources need to be propagated to the caching layers. There is no all-matching solution, however, Adobe AEM has enough mechanisms (such as flush URLs, JCR update triggers, replication URLs), all accessible via HTTP requests, which allow the caching state to be controlled automatically as part of the deployment process.

Deployment Process
AEM has a set of Maven archetypes and plugins which make it easy to build and deploy the code to environments. You can also include all the design artifacts, components, and even default content. This allows us to keep the single source of truth for all instances in all development environments in a source repository, and build new instances in existing or new environments via a maven build.

Backup and Restore
In AEM, the backup operation is simply "xcopy" of the application folder, and restore is just copying it somewhere else, and running there. Because of that, it's very easy to replicate or bootstrap AEM instances on-demand, so you can comfortably manage dozens of instances and environments at the same time.

Also, because these operations are so simple, they can be automated, so it's easy to support scenarios where environments need to be rebuilt or replicated. For example, creating DR Author or Publish instance after deployment, or restoring environments after data center failure.

So why no Continuous Delivery?
Considering how simple AEM architecture is, how straightforward and safe the deployment operations are, and how many tools and mechanisms AEM has in order to support deployments, it would be surprising if organizations did not implement Continuous Delivery on AEM. Of course, Continuous Integration and Deployment are not the only things that need to be implemented to achieve Continuous Delivery, but the remaining things are more to do with the organization's development and quality processes. And at least AEM is providing a great technological foundation in order to achieve smooth Continuous Delivery.