Solving AEM DevOps Challenges, Part 1: Inconsistent Environments

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.

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.

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.

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?