Off-topic
I have been working on Adobe Experience Manager projects for almost nine years. Within that time I saw three different approaches towards implementing and delivering AEM projects.
Implement, deploy & forget a.k.a. YOLO (You Only Live Once) development
No code reviews, no deployment automation, no performance tests, no security checks… You probably can already see where I am going with this. Because of unclear processes and the lack of proper quality assurance, the projects were not spectacularly successful.
Fortunately, this model is becoming less and less frequent (which was not a case just a few years back).
Compromise
Probably the most popular model where companies already noticed the need for automation and introduced some quality checks to their development processes. The cost is higher but the quality is much better. Still, there are certain elements that could be improved (e.g. cyclical performance tests, static code analysis, etc.).
Maturity
Full automation of the whole development cycle including environment provisioning, sophisticated deployments (including pre- and post-deployment steps), quality checks on every level (code, functional, non-functional). That is definitely the right direction, the North Star, so to speak. Obviously nothing is given for free, and it requires more effort to develop projects in such a way. But it pays off.
Cloud Manager
So, getting back to our original topic – Cloud Manager. What is that? As per Adobe’s documentation:
“Cloud Manager for Adobe Experience Manager (AEM) is a cloud service allowing customers to build, test, and deploy AEM applications (…) Cloud Manager enables customers to manage their custom code deployments on their AEM-managed cloud environments with manageable pipeline automation and complete flexibility for the timing or frequency of their deployment.”
ACM is an implementation of the development pipeline concept. It assumes a few steps as per the diagram below.
I would summarize its features into the following list:
- Continuous Integration / Continuous Delivery tool (well… to some extent)
- Automatic, scheduled or manual deployment
- Dispatcher cache invalidation
- “Quality Gates”: Code Inspection, performance testing and security validation
- API & CLI access
- Events/Webhooks
- Autoscaling features
Apart from deploying AEM applications, Cloud Manager also allows the deployment of custom Apache Web Server and Dispatcher configuration. Whereas some features are by default included in the basic configuration, we are free to customize and extend them, including:
Apache Virtual Hosts, Rewrite Rules, IP whitelisting, dispatcher filters, caching rules, renderers.
Since we can provide only one configuration per all nodes/environments, required customizations can be achieved by adding OS variables on nodes (AMS support required) or using Apache Variables in the configuration.
Regardless of all the detailed features, the most important thing to remember is that Cloud Manager is the only supported way to deploy your application to AMS.
Quality Gates
Let’s take a closer look at Quality Gates – there are three gates that your application must pass to be deployed in AMS.
Code quality testing
Cloud Manager uses SonarQube and OakPAL Content Rules to statically analyse the code and the content. It tests security, reliability, maintainability, coverage, skipped unit tests, open issues and duplicated lines of code. Unfortunately, there is no way to add your custom rule, but you can mark some of the detected issues as false-positives.
Security testing
It checks whether AEM Security Health Checks are met.
Performance testing
It tests both: page rendering and Assets performance. After 30 minutes, it provides a report outlining i.a., CPU utilisation, Disk IO Wait Time and Page Error Rate. Some of the parameters of the test are configurable (e.g. traffic level), but generally speaking, it is rather a non-customizable element of Cloud Manager
For each of the above mentioned Quality Gates, Adobe introduced the concept of the three-tier result:
- Critical – these are issues identified by the gate which cause an immediate failure of the pipeline
- Important – these are issues identified by the gate which cause the pipeline to enter a paused state. A deployment manager, project manager, or business owner can either override the issues, in which case the pipeline proceeds or they can accept the issues, in which case the pipeline stops with a failure
- Info – these are issues identified by the gate which are provided purely for informational purposes and have no impact on the pipeline execution.
As things stand now, I would definitely recommend undertaking a proper performance test prior to the go-live. Tests that Cloud Manager provide are rather elementary and give some kind of a feeling about the status of the system but definitely do not provide a full spectrum of information regarding the application’s performance.
What does Cloud Manager mean to my project?
Let’s think about the consequences, requirements and finally the pros and cons of using Cloud Manager.
First of all, as I mentioned at the beginning of this article, Cloud Manager is now the only official way of deploying new applications to AMS. It is supported by Adobe and it imposes some standards and good practices.
Thanks for introducing the quality gates, I am almost sure that on average the quality of all AEM projects will increase (remember YOLO development?). On the other hand, what if we want to deploy an artefact rapidly to fix a critical issue on the production? That is still an open question for me.
Even if it is closed for any custom modifications it still exposes API and CLI than you can use in more sophisticated scenarios. That is opening a gate for more mature organisations, which might consider using Cloud Manager as a part of their Pipeline.
An indisputable advantage is a fact that the Cloud Manager is “connected” with the AEM as a Cloud concept and, consequently it offers the automatic upscaling mechanism.
There are also certain requirements/prerequisites that your project must meet if you are to use Cloud Manager. First of all, the project code must be synchronized with Adobe’s GIT repository. Naturally, it does not mean that you cannot use your own repository on a daily basis. You just need to take care of synchronization with Adobe. That introduces an additional complicacy and may not be seen as a positive change by large organisations.
Similarly, Cloud Manager does not support private artifact repositories (like Nexus).
One has very limited control over Quality Gates, and in some scenarios that might cause certain difficulties. Consider an example where you do have your own Code Quality rules implemented in SonarQube – you can’t just add them to Cloud Manager, you are rather forced to configure and deploy your own SonarQube instance and make it a part of your own Pipeline.
To use Cloud Manager you must also be using Maven (ideally the official archetype proposed by Adobe). If you want to rely on Gradle, you have to find a workaround (e.g. dual build systems).
One of the elements that I miss is the possibility to deploy non-AEM services (e.g., search engines, backend web apps). If your architecture is more complicated than just AEM, you have to provide all of that on your own and use Cloud Manager to deploy only AEM parts.
Additionally, if you would like to keep non-AMS environments (e.g. for the sake of testing) you will not be able to use Cloud Manager. All the deployment procedures, tests, etc. must be done again. By yourself.
API
Thanks for exposing the API, Cloud Manager may become a powerful part of a more sophisticated Pipeline. As per Adobe’s documentation:
There are a variety of use cases enabled with this API, including:
- Starting the Cloud Manager CI/CD pipeline from an external system.
- Executing additional tests between the standard Cloud Manager performance tests and the ultimate production deployment.
- Triggering additional activities after the pipeline execution is complete or a specific step has been completed, for example
- CDN cache invalidation once the production deployment is finished.
- Deploying related applications to non-Managed Services systems.
- Notifying on other channels (e.g. Slack, Microsoft Teams).
- Creating issue reports in bug tracking systems (e.g. Atlassian JIRA) on pipeline failures
Evolution
I have been observing Cloud Manager since the very beginning and my opinion has changed a little over time. Monthly releases bring new features, improve stability and introduce missing elements (like downloadable logs). There are still a lot of open topics, stability issues and missing bits and still, some of the companies developed better solutions for their internal usage. But at the end of the day, Cloud Manager is a step in the right direction. It just needs more time to stabilize.
Summary
At the beginning of this article, I mentioned three types of companies/projects. For each of those, the introduction of Cloud Manager means some effort. Companies that were not taking enough care of proper processes, automation and quality assurance will require a revolution. And that’s outstanding news.
For conscious and mature organizations, Cloud Manager must be incorporated into the current processes, pipelines and standards. Is that good? Not always probably.
