6.3 Cloud Manager CI/CD Pipelines & Quality Gates

6.3 Cloud Manager CI/CD Pipelines & Quality Gates

Quick Answer: Cloud Manager builds and validates AEM application code before deploying it. Code Quality uses three documented categories: Critical findings fail immediately, Important findings pause the pipeline for override or rejection, and Info findings do not affect execution. Combined unit-test coverage below 50% is an Important finding. Production deployments are rolling updates, so old and new application versions can run at the same time during replacement.

Pipeline Types

A production pipeline builds a release, deploys it to Stage, runs the configured test steps, applies approval or scheduling gates, and then deploys the same artifact to Production. A non-production pipeline can deploy to a development environment or run Code Quality without deployment. The exact stages depend on program type and pipeline configuration, so do not memorize an invented universal sequence.

A typical production flow is:

1. Build: Cloud Manager checks out the configured branch, executes the Maven build, runs unit tests, and creates the deployable application artifact.
2. Code Quality: SonarQube analysis, AEM-specific rules, content-package checks such as OakPAL, and Dispatcher validation evaluate the source and packages.
3. Stage deployment: The release is deployed to the Stage environment.
4. Stage verification: Configured functional tests, custom UI tests, experience audit, and performance testing run where applicable. Adobe does not document a separate generic OWASP security-test step for every AEM as a Cloud Service production pipeline.
5. Approval and scheduling: Authorized roles review results and approve or schedule production deployment when the pipeline configuration requires it.
6. Production deployment: Cloud Manager performs a rolling update and reports deployment status.

Code Quality Gate

Code Quality issues are grouped by action, not by informal labels such as minor or blocker:

The category of a metric matters. For example, the documented security-rating threshold is Critical, while maintainability and coverage thresholds are Important. A developer should inspect the actual report instead of assuming every warning has the same effect.

Coverage Is Combined, and Below 50% Is Important

Cloud Manager defines coverage as a combination of covered executable lines and evaluated conditions. The reported formula considers covered lines plus true and false branch outcomes. The failure threshold is less than 50%, and the category is Important. Therefore:

• 50% is the threshold for avoiding the coverage finding.
• It is not described as line coverage of only the core bundle.
• Falling below 50% pauses an ordinary deployment pipeline rather than causing an unconditional Critical failure.
• Teams should still treat low coverage as a defect and add meaningful tests instead of relying on an override.

Use JUnit, Mockito, and AEM Mocks for isolated service and Sling Model behavior. Coverage is a signal, not proof that assertions are useful.

Dispatcher Validation

The Dispatcher module is part of the application release. The AEM as a Cloud Service SDK Dispatcher Tools provide local validation and container execution. Run the validator against the source configuration before pushing. It checks supported structure, includes, Apache syntax, and cloud restrictions. Cloud Manager repeats validation; an invalid farm, virtual host, include, or unsupported directive prevents a safe deployment.

Useful local workflow:

bin/validate.sh src
bin/docker_run.sh src host.docker.internal:4503 8080

Local validation does not replace Stage testing. It catches configuration defects early while the Stage environment verifies the assembled release in cloud infrastructure.

Rolling Deployment and Compatibility

Cloud Service customer releases use a rolling strategy. Nodes with the old release continue serving while nodes with the new release start and pass readiness checks. Ready new nodes take traffic and replace old nodes over time. The platform does not require a single all-at-once DNS cutover between named blue and green clusters.

The rolling model creates an important compatibility window:

• Old and new code may run simultaneously.
• Both releases can observe the shared mutable repository.
• New or modified indexes are prepared before new nodes take traffic; old nodes continue with the old indexes during the transition.
• Mutable content is applied after the rolling code replacement.

Design repository changes so both releases can read the transitional shape. Add a new property before removing an old one, tolerate both formats for at least one release, and spread service-user or ACL changes across releases when older code still depends on the old authorization model. Repoinit and content migrations are not a substitute for backward-compatible application logic.

Exam Decision Rules

• A Critical Code Quality issue fails; an Important issue pauses; an Info issue reports only.
• Coverage below 50% is Important and uses combined line-and-condition coverage.
• A code-quality-only pipeline cannot override Important failures.
• Dispatcher syntax and cloud-layout errors must be fixed before deployment.
• Production deployment is rolling, so reason about coexistence of old and new code.

Reading Cloud Manager Results Correctly

A Code Quality report combines generic Java analysis with AEM-specific package and repository rules. Always use the category assigned in the report:

The documented thresholds are metric-specific. Security rating below B and reliability rating below D are Critical. Maintainability below A and combined unit-test coverage below 50% are Important. Skipped tests and open issues are informational at their documented thresholds. This is why the phrase “quality gate failed” is not enough to predict the action; inspect the category.

Coverage Formula and Test Quality

Cloud Manager coverage combines covered lines with branch conditions evaluated true and false. It is not simply a percentage of Java lines in one Maven module. A result below 50% produces the Important finding. Tests should still verify behavior rather than chase a number: assert model adaptation, service fallbacks, authorization boundaries, error paths, and integration contracts.

Dispatcher and Package Validation

The build analyzes FileVault packages and Dispatcher configuration before deployment. Use the same SDK Dispatcher Tools locally, keep the supported conf.d and conf.dispatcher.d layout, and fix invalid includes, unsupported directives, broken links, and farm syntax. Package validation also checks application/content separation and repository constraints. The exact reported category comes from the current rule set, so avoid labeling every build defect a Critical code-quality issue.

Rolling-Release Checklist

During a rolling deployment, design for a temporary mixed-version state:

• keep old properties readable while introducing replacements;
• make service-user and ACL changes compatible with both releases;
• avoid startup migrations that assume only one node is active;
• version custom indexes according to Cloud Service guidance;
• validate rollback compatibility with new mutable content;
• remove deprecated structures only in a later release after old code no longer depends on them.

A rolling deployment is an availability mechanism, not a transactional schema migration. Health checks determine when new nodes take traffic, but they cannot repair application-level incompatibility.