Study guide
6.3 Cloud Manager CI/CD Pipelines & Quality Gates
Adobe Certified Professional - AEM Sites Developer AD0-E128
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Dispatcher Farm & Multi-Site Configuration
1.1 AEM Dispatcher Configuration & Caching Fundamentals 1.2 Multi-Site Management (MSM) & Blueprint/Live Copy Architecture 1.3 OSGi Configuration Management & Run Modes (.cfg.json)
2 Chapter 2: Oak Indexing & Custom Logging
2.1 Custom Oak Index Definitions & Lucene Query Optimization 2.2 AEM Custom Logging, Logback Configurations & Request Tracing
3 Chapter 3: Component Architecture, HTL & Client Libraries
3.1 Core Components & Proxy Component Pattern 3.2 HTL (HTML Template Language) Block Statements & Context-Aware Escaping 3.3 Client-Side Libraries (Clientlibs) Architecture & Management
4 Chapter 4: Sling Models & OSGi Declarative Services
4.1 Sling Models Framework, Injectors & Model Exporter 4.2 OSGi Declarative Services, Component Lifecycle & Service Rankings
5 Chapter 5: Templates, Fragments & Business Workflows
5.1 Editable Templates, Structure, Initial Content & Content Policies 5.2 Content Fragments, Experience Fragments & Headless Delivery 5.3 AEM Workflows, Custom Process Steps & Launchers
6 Chapter 6: Build, Packaging & Cloud Manager CI/CD
6.1 Maven Project Structure & AEM Project Archetype 6.2 Content Package Types, Packaging Rules & FileVault Validation 6.3 Cloud Manager CI/CD Pipelines & Quality Gates 6.4 Rapid Development Environments (RDE) & Sling Repoinit Scripts
7 Chapter 7: Environment Maintenance & Content Distribution
7.1 AEM Maintenance Releases & Cloud Service Version Updates 7.2 AEM Deployment Topologies & Cloud Architecture 7.3 Replication Agents & Sling Content Distribution 7.4 Repository Maintenance: Revision Cleanup, Compaction & Purge Tasks
8 Chapter 8: Analyzing, Debugging & Diagnostic Tools
8.1 System Log Analysis & Diagnostic Tooling 8.2 Debugging Client-Side Libraries & Granite Dumplibs 8.3 Dispatcher Caching Diagnostics, X-Cache-Info & Local Validation 8.4 Environment Troubleshooting, Web Console & Developer Console
6.3 Cloud Manager CI/CD Pipelines & Quality Gates
Key Takeaways Explain This Topic AI
Cloud Manager production pipelines build once, deploy to Stage, run configured tests and approvals, and then deploy the same artifact to Production; non-production pipelines target development environments or run code-quality checks.
Code Quality findings use three categories: Critical fails immediately, Important pauses for override or rejection, and Info does not affect execution. Important findings cannot be overridden in a code-quality-only pipeline.
Cloud Manager reports combined line-and-condition unit-test coverage; coverage below 50% is an Important finding, not an unconditionally fatal blocker.
Dispatcher configuration must pass the SDK validator and Cloud Manager validation before deployment.
AEM as a Cloud Service uses rolling deployments: ready nodes with the new release replace old nodes gradually while both releases may temporarily share mutable content.
Last updated: September 2026
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:
Build: Cloud Manager checks out the configured branch, executes the Maven build, runs unit tests, and creates the deployable application artifact.
Code Quality: SonarQube analysis, AEM-specific rules, content-package checks such as OakPAL, and Dispatcher validation evaluate the source and packages.
Stage deployment: The release is deployed to the Stage environment.
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.
Approval and scheduling: Authorized roles review results and approve or schedule production deployment when the pipeline configuration requires it.
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:
Category Pipeline behavior Override behavior
Critical Immediate pipeline failure. Cannot proceed until corrected.
Important Pipeline pauses for a decision. An authorized user may override or reject it in a deployment pipeline; a code-quality-only pipeline cannot override it because Code Quality is its final step.
Info Reported for awareness. No effect on pipeline execution.
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.
Loading diagram... Cloud Manager Production CI/CD Pipeline Execution & Quality Gate Architecture
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:
Category Result
Critical The pipeline fails immediately.
Important A deployment pipeline pauses for an authorized override or rejection. A code-quality-only pipeline cannot override it.
Info The finding is reported without changing pipeline execution.
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.