Adobe Managed Services (AMS) is a popular offer for hosting and operating AEM environments. In AMS setups, deployments to production are usually delegated to their engineers, so-called Customer Success Engineers (btw. fancy name, isn't it?). However, the process still requires some involvement of development team, it's sometimes slow and error-prone and, to be honest, much against the DevOps approach (separate teams for development and deployments). Not to mention lack of automation and a need to raise formal change requests in form of a Word-ish documents… Painful.

Adobe team has, of course, been aware of these issues and now is proposing a new way of deployments - an automated process based on their in-house solution called Cloud Manager (CM). What can you expect from it? I'm currently playing with CM in a sandbox environment provided by Adobe and sharing my initial thoughts below.

Is it a replacement for my Jenkins?

The first question which came to my mind when I first heard about Cloud Manager was “is it going to replace my CI/CD tools”? The answer for now is “no”. Although the most basic setups can solely be run with Cloud Manager, in practice you would need a dedicated automation toolkit (like Jenkins, Bamboo or similar). Why is it so? Adobe is not going to create their own general-purpose automation tool. The CM is a deployment utility tailored for specific needs of AEM architectures: it can build an AEM-compatible code and configurations, deploy it to AEM and dispatcher and run some tests to verify the correctness. This is the current state. All of the steps and tasks are designed to meet Adobe’s recommendations around development and deployments for AEM. If you’d like to perform some additional tasks which are not built-in into CM (e.g. run your own test suite or perform some post-deployment operations on content) there’s no way of doing so from within CM. For these steps you still need your custom tools.

Home screen of Cloud Manager Example home screen of Cloud Manager

Delivery platform for AEM projects with Cloud Manager

The drawing below depicts an architecture of simple delivery platform for AEM-based system. What can you see there? There are two major actors in the whole picture: Jenkins and Cloud Manager. Of course, you can substitute Jenkins with whatever automation tool you like. The master tool in the delivery process is Jenkins as it originates the deployment action. Jenkins communicates with CM using Adobe’s APIs.

Delivery platform with Cloud Manager Outline of a delivery platform with Cloud Manager

The essential aspect of this solution is the code repository. Note that CM can’t use your Git repo. Does it mean you need to rely on Adobe repos only? Fortunately, no. The idea is to do the development with the repo and dev tools you like (Bitbucket, Github, you name it) and if you’re ready for deployment, the code must be pushed to Adobe’s repo. You can do this simply by setting a dedicated remote on your repository and push the code there as a first step in your Jenkins job.

After Jenkins notifies CM to start the process/pipeline, the CM is the one to build the code. And here’s my first big concern. Adobe forces you to use Maven in order to build the code. It doesn’t need to be based on Adobe’s Maven Archetype, but Maven is a must. At Cognifide, we’ve been using Gradle for a couple of years now with some great results and feedback from the community (see Gradle AEM Plugin) so we need to figure out how to marry up Gradle world with Adobe’s requirements to use Maven.

Cloud Manager performs a handful of tasks during the pipeline execution. I’m not going to cover all the details now but at this stage it's important to know that the build process of your code must produce an AEM package and zipped Dispatcher configuration. They are then deployed correspondingly. On production environment you can expect a rolling deployment for your publish instances - this is actually quite nice that it’s fully automated and you don’t need to worry about it anymore.

After the code is successfully deployed, CM runs a suite of performance tests. And when it’s done it can notify Jenkins back using web hooks mechanism. This is a time when you can also run additional tests and do whatever else is needed: deploy your AWS Lambda code, clean CloudFlare cache, perform some content clean up, etc.

A word on performance tests. Although they are not fully documented yet, Adobe can use your production traffic (list of popular pages) to perform the tests and check for number of system parameters. The threshold values for things like response times, CPU utilization or disk bandwidth are all configurable. Nice.

Hot or not?

And here we are - is Cloud Manager a tool you’d love? Of course, the answer is not simple and depends on many factors. We must also remember that this is a relatively new solution and Adobe is improving it a lot every month. I’m listing some pros and cons of Cloud Manager below but please bear in mind that they are only valid at the time of publication and you have to evaluate them in terms of your own setup.

Pros:

  • You don’t need Adobe’s engineer anymore in order to perform a production deployment.
  • The process is fully automated and much less error-prone.
  • Cloud Manager runs a number of checks before your code gets deployed so you can be sure it meets most of Adobe standards and recommendations.
  • It’s tailored to specific needs of AEM-based system, so you don’t need to worry about clearing dispatcher cache, backups before deployments or rolling deployment to all publish instances - these types of tasks are already there.
  • It provides a promising approach to performance testing so you can save some effort on creating your own performance test suite.
  • It’s integrated with Adobe Experience Platform so (in theory) deployments can be done by non-technical person from your organization.

Cons:

  • You still need a complementary automation tool like Jenkins in order to perform automated tasks needed by your system
  • Code must be based on Maven and it’s built in Cloud Manager rather than in your Jenkins
  • There’s no decent release management as of now (something comparable with Bamboo) - you have to manage the versions of your software on your own or integrate it somehow with Jenkins/Bamboo (it may be tricky though as the code is built in CM)
  • The main pipeline currently assumes use of two environments only, so you can’t promote your released code through all environments of your pipeline (as you would expect from a standard DTAP setup: Development - Testing - Acceptance - Production). You can build so-called non-production pipelines but they are separated from the main one (separate build process)
  • Although CM follows API-first design, it currently supports some basic events only. Hence, it may be hard to achieve more complex pipelines which require additional steps to be performed along the pipeline
  • Cloud Manager is only available to Adobe Managed Services customers - it can’t be run to support on-premise setups.

Cloud Manager is definitely a great and important step into automated deployments for AEM systems run by Adobe Managed Services. Although it may currently miss some "features" I got used to have within my CI/CD pipelines, I'm sure it will quickly become a popular and comprehensive tool.