Solving AEM DevOps Challenges, Part 1: Inconsistent Environments

Solving AEM DevOps Challenges, Part 1: Inconsistent Environments

Over the last 10 years of working with Adobe Experience Manager and JCR related technologies, we’ve dealt with hundreds of AEM projects and many processes. We have seen a variety of challenges in dealing with the AEM infrastructure and development landscape, in particular, where those two meet. We asked ourselves, how do we increase efficiency and reliability for both our developers and our enterprise clients while making AEM development feel more enjoyable and competitive with modern frameworks? Our answer is AEM Cloud.

Over the next few articles, we’ll discuss several challenges that we see in the ecosystem that we wanted to correct and how AEM Cloud does it. The first is Inconsistent Environments.

Challenge 1: Inconsistent Environments

The first challenge we sought to solve was the constant battle of keeping the different environments consistent. Lower environments are constantly missing production content, during application upgrades there could be multiple versions of the same environment, and feature development was always a black hole of different developers working on whatever stack they were able to put together. Keeping these environments consistent proved to be a time consuming and difficult task.

Solution: AEM Cloud Docker Images, AEM Cloud CLI, and AEM Cloud On-Demand Environments

Automatic provisioning of an environment based on application specification and configuration was a must. Looking at the technology landscape, Docker would allow us to create a version of the production environment stack in a reproducible way. We used Docker containers to easily create an environment that had the same OS, Java, Maven, and AEM version along with any service packs needed to match production.

This increases efficiency on two fronts:

1 — Local Development Environments: With AEM Cloud, a developer creates an environment on their local machine simply by cloning the project codebase and running ‘aemcloud up’. The developer now has a running AEM instance that matches production’s runtime environment with all the configurations.

2 — Hosted Pre-Production Environments: Once developers have completed a new feature and pushed their changes to a remote git repository, a new on-demand AEM environment is available with the exact same runtime and configuration as production. Not only does this guarantee consistent environments and make disaster recovery much simpler. This also introduces a whole new paradigm for Continuous Delivery, which we’ll address later.

Want to learn more? AEM Cloud.

Other articles in this series:

Part 2 Relevant Content

Part 3 Slow Development Cycles

Part 4 Cumbersome Release Process