The Adobe Cloud Manager has a CI/CD pipeline that is offered by Adobe for AEM Cloud Services (AEM CS) as well as Adobe Managed Service (AMS) setups. Cloud Manager is a self-service UI to manage your AEM environments, deployments and comes with a couple of other tools and functionalities, such as a GIT repository, automated testing and code quality checks.

For a general introduction to Cloud Manager, please refer to the official documentation:

This article will focus on the source code quality checks that are an integral part of the Cloud Manager deployment pipelines.

About code quality checks

Monitoring the quality of your source code is vital to ensure high overall quality of your application and to allow for stable and easy to maintain setup. Even for experienced senior developers, it helps to avoid human error and makes it easier for teams to level the quality of your outputs.

In the context of AEM, Cloud Manager enforces quality gates because Adobe will be responsible to meet service level agreements (SLAs) when hosting and running AEM for you (being it on AMS or as Cloud Service). Putting up some guardrails and enforcing them through quality metrics is a vital part in meeting high expectations that customers have towards Adobe.

The differences

Cloud Manager itself as well as the code quality rules are different for AMS compared to Cloud Services. This video outlines some key differences in Cloud Manager:

Screenshot from the AEM as a Cloud Service – Cloud Manager video (see 4:35)

While for both offerings Cloud Manager does include code quality checks, there are different rule sets applied. You can find a list of the rules as XLS files:

The rules

Cloud Manager makes use of SonarQube for code quality checks. While there are other tools for source code analysis available, it makes sense to lok into SonarQube if you want to get your own setup close to what Cloud Manager checks. Otherwise you might need to map the listed rules to the rule sets available in your tool chain which might be quite some effort and in some cases hard to accomplish.

This article will not cover setting up a SonarQube server but there is a Docker image available and this article outlines the setup of SonarQube and the integration with SonarLint pretty well.

Looking at the rule lists above, you can spot different rule sets/categories that are combined for AEM. Many of them are standard rules (such as squid, findbugs, findsecbugs) that are included in SonarQube by default. You might want to double check that all relevant rules are activated on your SonarQube. In addition you can also tailor the applied rule set to reflect certain guidelines or guard rails you or your organization might have. Additional information on these rules including code examples can be found on the SonarQube user guide and their rules documentation.

The rule key prefix “AEM Rules” refers to the AEM Rules for SonarQube, an add on rule set specifically tailored to spot different code quality issues when programming for AEM. Adding this rule set to your SonarQube will get you pretty close to what Cloud Manager checks.

There is another 3rd party rule set available that is based on the AEM Rules but not part of Cloud Manager quality checks. It might still be interesting to evaluate for you based on your requirements.

There are two more categories of rules contained in the list: Some without prefix (e. g. IndexType or ReverseReplication) and some with the prefix “CQRules“. These are custom rules built by Adobe and unfortunately not publicly available for usage outside of Cloud Manager. You can find the documentation of these rules for AMS / AEM 6.5 as well as Cloud Services with explanations on the checks and code examples. Unfortunately, you won’t be able to add these checks to your own Sonar setup unless you (re-) implement them as part of your own rule set.

Some of the custom rules are based on the Oak Package Acceptance Library (short: OakPAL), an open source tool to validate content packages that you might also want to check out.

Integrating code quality checks into the development cycle

Integrating code quality into your development cycle needs a bit of setup but will pay off pretty fast. I have seen developers happily pushing their code to Cloud Manager, deploying to development environments while overriding and ignoring the quality check results and still being surprised by failed quality gates when trying to promote their code to staging and production environments.

The earlier you can get feedback on the quality of your code, the faster and easier it is to resolve potential issues. Therefore you want to apply the quality checks as early as possible into your development cycle. My recommendation is a multi-tier setup of code quality checks.

Local checks

Most modern IDEs already come with certain source code validation features. To optmize the setup, you may want to look into SonarLint, which is available as a plugin for a variety of common IDEs such as Eclipse, IntelliJ, VS Code and others. SonarLint can run in a stand-alone manner or be integrated with your SonarQube server (so called Connected Mode). Only with the latter, you will be able to apply your tailored rule set as the stand-alone setup is only able to work with a predefined set of rules.

Running your own SonarQube

Setting up a self-hosted SonarQube server (or using their SaaS offer SonarCloud) allows you to tailor your own set of rules as outlined above and apply it whenever a developer checks in new code. This will allow you to cover a good variety of code quality checks even before pushing your code to Cloud Manager.

Cloud Manager quality check pipelines

The first “real-world” validation comes into play after you pushed your code to Cloud Manager. Depending on your configuration, a pipeline can run automatically or be triggered manually after you pushed new code. If you just want to evaluate your code and not yet deploy anything to the environments, you can leverage Code Quality Pipelines (see documentation for AMS and CS). A Code Quality Pipeline will build your code and execute all checks but terminate before deploying anything. Using Code Quality Pipelines will allow you to receive feedback and address potential issues before a deployment. I highly recommend to run them automatically whenever you push code to Cloud Manager.

Actual deployment

During an actual deployment, code quality checks will be executed automatically by Cloud Manager. It is a good idea to only deploy your code if all quality gates are met although it is possible to manually override failed checks (see FAQ for AMS and CS).

Additional Resources