AEM as a Cloud Service -Deployment Process
Using Adobe Experience Manager for Cloud Deployments
You might be aware that AEM (Adobe Experience Manager) as a Cloud Service is the latest AEM product line offering. If you are already using AEM, you don’t have to provide training to your authoring team when moving to the cloud version, as it offers the same interface for authors.
Regarding code development, AEM as a Cloud Service is similar to the AEM On-Premise and Managed Services solutions, where developers write the code, test it locally, and then push it to the remote git repository. But there is a major change in terms of code deployments and updates to the newer AEM version, as this is all managed through the cloud manager only.
Cloud Manager is the CI/CD (Continuous Integration and Continuous Delivery) pipeline used when you want to deploy new features to AEM as a Cloud Service. It’s a cloud service allowing you to build, test, and deploy new releases of your website in the Cloud. Hosting, operation, and scaling of AEM are all managed by Adobe.
In this post, I will describe how developers can use cloud managers to deploy AEM as a cloud service and provide more details about how we can use it for code scanning and unit testing.
Deployment architecture
Cloud manager manages all updates to AEM as a cloud service, and it is the only way to build, test and deploy customer applications to the author and publish environment. The update can be triggered by Adobe when a new version is ready or by the customer when a new application code is ready.
The concept of a deployment pipeline is bound to each environment within a program. Whenever the cloud manager pipelines run, it creates a new version of customer code by combining the recent customer application code and adobe baseline image. Also, Adobe can add changes in their baseline image, which will be deployed using the same pipelines. Below is the architectural diagram for cloud deployment, which gives an overview of all steps performed on non-prod / prod environment pipelines.
Cloud manager deployment steps
Below are the deployment steps for the cloud manager.
- Log in to experience.adobe.com (Experience Manager / Cloud Manager)and access the cloud manager option. If you do not have access, your organization does not yet have the AEM Cloud Service licenses or sandbox access, or your account lacks the required permissions.
- Then you can see all configured environments and deployment pipelines.
- Cloud Manager allows git repositories hosted by Adobe or external both. The pipeline can only fetch code from those configured repositories. To use an external non-Adobe repository, the changes must be synchronized with the Adobe repository.
- From configured pipelines, you can start deployment to the environment. There are two types of environments, and each environment consists of a full AEM stack (author, publish, and dispatcher). Production consists of Stage and Prod environments. All other environments are called non-prod environments, serving as dev or QA environment for testing.
- Once you trigger any deployment, your pipeline has been verified against a set of pre-defined rules.
- The next step is build/unit testing, where your application code has been tested for quality and compiled into a build artifact (In Maven terminology, an artifact is an output generated after a Maven project build).
- Once code is compiled, the pipeline inspects the whole code base and applies static code analysis. It includes topics like test coverage, security scanning, and code duplication. In the below image, you can get more details related to code scanning as it provides information related to critical thresholds of our scanned code, which internally uses SonarQube. If critical thresholds fail, pipelines will stop immediately; if important thresholds fail, pipelines will pause and not automatically proceed to the next step. But you can override the scan result to move to the next steps in the current release, which can be fixed later.
- Now the artifact will be built into the runnable image and deployed to the pipeline-configured environment (dev/stage). During deployment on stage, internally cloud manager creates a whole stage environment copy so that if any issue occurs during deployment, the stage can be reverted to the previous state. Once stage development finishes, it automatically moves to the stage testing step. The image below lists all steps performed from stage deployment to production deployment. Each step needs to be successful. Then only it can be moved to the next step.
- During stage testing, various tests like security, performance, and load UI are executed by default by Adobe to test whether AEM is still working as expected. Additionally, we can add custom tests for the integration testing of the application. The below image gives a review of sites has been audited against a set of rules to validate content quality, performance, and user experience. This gives us a lighthouse report compared to our last release. This report is generally generated through chrome dev tools to get a performance review.
- If not configured on the pipeline, the deployment will stop after stage testing so that manual testing can be performed and stage testing results can be verified before deploying to production.
Once you approve the build, the code will go to production; otherwise, it will be reverted.
Deploying Content Packages via Cloud Manager and Package Manager
AEM Cloud services require a separation of content and code, which means a single content package cannot deploy to both /apps and runtime-writable areas. Customer custom code should always be deployed through the cloud manager, but content packages written for AEM can also be deployed through the package manager as it requires a clean separation of immutable and mutable content. The diagram provides recommended project structure and content package artifacts.
The code under path /apps and /libs are considered immutable areas with AEM. They cannot be created/updated/deleted once AEM starts; if you try to change content under this path, it will fail. Apart from the above paths, i.e., /content, /conf, /etc, /oak: index, /system, /temp, and /var paths are considered mutable areas as they can be changed at runtime.
Conclusion
Adobe Cloud Manager provides out-of-the-box enterprise-grade CI/CD and hosting of AEM applications in the cloud.
As you can see, it is a big cost-saving potential for both the initial setup and maintenance due to simple configuration in the web UI and all the operation efforts being taken care of by Adobe.
