Documentation AEM Cloud Manager Documentation for AEM 6.x

Add a non-production pipeline configuring-non-production-pipelines

Last update: March 26, 2026

Topics:
Cloud Manager

CREATED FOR:

Admin

Learn how to use Cloud Manager to create and configure non-production pipelines to deploy your code. If you would first like a more conceptual overview of how pipelines work in Cloud Manager, see CI/CD Pipelines.

Overview overview

Using the Pipelines tile in Cloud Manager, the Deployment Manager can create two different types of pipelines.

Production Pipelines - A production pipeline is a purpose-built pipeline made of a series of orchestrated steps to take source code all the way into production.
Non-Production Pipelines - A non-production pipeline primarily serves to run code-quality scans or to deploy source code into a development environment.

This document focuses on non-production pipelines. For details on how to configure production pipelines see the document Configuring Production Pipelines.

There are two types of non-production pipelines:

Code Quality Pipelines - These run code quality scans on the code in a Git branch and executes the build and code quality steps.
Deployment Pipelines - Along with performing the build and code quality steps like the code quality pipelines, these pipelines also deploy the code to a non-production environment.

NOTE

You cannot set up a pipeline until its associated Git repository has at least one branch and program setup is complete. See Cloud Manager Repositories to learn how to add and manage repositories in Cloud Manager.

Add a new non-production pipeline add-non-production-pipeline

After you set up a program and at least one environment in the Cloud Manager UI, you can add non-production pipelines. Use these pipelines to test your code quality before you deploy to production environments.

Log into Cloud Manager at my.cloudmanager.adobe.com and select the appropriate organization and program.
From the Cloud Manager home screen, open the Pipelines card and click Add, then select Add Non-Production Pipeline.
On the Configuration tab of the Add Non-Production Pipeline dialog box, select the type of pipeline you want to create, either one of the following:
- Code Quality Pipeline - Creates a pipeline that builds the code, runs unit tests, and evaluates code quality without deploying to an environment.
- Deployment Pipeline - Creates a pipeline that builds the code, runs unit tests, evaluates code quality, and deploys to an environment.

Code Quality Pipeline - Configuration tab

table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3
Section	Option	Description
Pipeline Configuration	Non-production Pipeline Name	Enter a description for your pipeline in the Non-Production Pipeline Name field.
	Testing	Visible only when editing a non-production pipeline. The UI shows the testing categories that the pipeline runs as part of code quality validation. Static Code Testing - Analyzes the code for quality and correctness issues. Load/Performance Testing - Evaluates performance-related behavior as part of pipeline testing. Security Testing - Checks the code and pipeline output for security-related issues.
Deployment Options	Deployment Trigger	Manual - Lets you manually start the pipeline. On Git Changes - Starts the pipeline when commits are added to the configured Git branch. With this option, you can still start the pipeline manually, as required.
	Important Metric Failures Behavior	Ask every time - This behavior is the default setting and requires manual intervention on any important failure. Fail immediately - If selected, the pipeline is canceled whenever an important failure occurs. It essentially emulates a user manually rejecting each failure. Continue immediately - If selected, the pipeline procedes automatically whenever an important failure occurs. It essentially emulates a user manually approving each failure.
	Approve after Stage Deployment check box	Visible only when editing a non-production pipeline. Select this option to require approval after deployment to the stage environment before the pipeline can continue. If this option is not selected, the pipeline continues based on the configured behavior.

Deployment Pipeline - Configuration tab

table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3 6-row-3 7-row-3 8-row-3 9-row-3
Section	Option	Description
Pipeline Configuration	Non-production Pipeline Name	Enter a description for your pipeline in the Non-Production Pipeline Name field.
	Eligible Deployment Environment	If your pipeline is a deployment pipeline, you must select which environments where Cloud Manager deploys the code.
	Testing	Visible only when editing a non-production pipeline. The UI shows the testing categories that the pipeline runs as part of code quality validation. Static Code Testing - Analyzes the code for quality and correctness issues. Load/Performance Testing - Evaluates performance-related behavior as part of pipeline testing. Security Testing - Checks the code and pipeline output for security-related issues.
Deployment Options	Deployment Trigger	Manual - Lets you manually start the pipeline. On Git Changes - Starts the pipeline when commits are added to the configured Git branch. With this option, you can still start the pipeline manually, as required.
	Important Metric Failures Behavior	Ask every time - The default setting and prompts the user to decide how to proceed when an important metric fails. Fail Immediately - The pipeline is canceled whenever an important metric fails. It is essentially emulating a user manually rejecting each failure. Continue Immediately - The pipeline proceeds automatically whenever an important metric fails. It is essentially emulating a user manually approving each failure.
	Approve after Stage Deployment check box	Visible only when editing a non-production pipeline. Select this option to require approval after deployment to the stage environment before the pipeline can continue. If this option is not selected, the pipeline continues based on the configured behavior.
	Skip Load Balancer changes check box	Select this option to prevent the pipeline from making load balancer changes during deployment.
	Dispatcher Configuration	The Deployment Manager role can configure a set of content paths that are either invalidated or flushed from the AEM Dispatcher cache when a pipeline is run. Cloud Manager runs these cache actions as part of the deployment pipeline step, just after any content packages are deployed. These settings use standard AEM Dispatcher behavior. To configure `Dispatcher`, do the following: Under PATH, provide a content path that you want the pipeline to flush or invalidate. Under TYPE, select the action to be taken on that path. Flush - Perform a cache deletion on the specified path. Invalidate - Perform a cache invalidation, similar to when content is activated from an authoring instance to a publishing instance. Click Add Path to add your specified path. You can add up to 100 paths per environment.
Pipeline	Experience Audit check box	Select this option to include an Experience Audit step in the pipeline. When enabled, the pipeline includes the Experience Audit step after the Source Code tab.

In the lower-right corner of the Add Non-Production Pipeline dialog box, click Continue.
Select the type of code the pipeline is configured to build and deploy.

Source Code tab - Full Stack Code

Deploys the complete AEM application, including application code and, by default, web tier configuration.

table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3
Section	Option	Description
Source code	Repository	From the drop-down list, choose the Git repository that the pipeline uses as its source. Cloud Manager builds code from the repository that you choose here.
	Git Branch	From the drop-down list, choose which branch in the selected repository the pipeline should build from. The default is `main`. The pipeline uses the chosen branch as the source for build and deployment. If necessary, click Refresh to update the list of available branches for the selected repository. Use this option if a recently created branch does not appear in the list.
	Build Strategy	Full Build - Builds all modules in the repository every time BETA Smart Build - Builds only modules that have changed since the last commit. Learn more about using Smart Build in a non-production pipeline. Important : Smart Build is available only for Code Quality pipelines and Dev Full Stack Code deployment pipelines.
	Ignore Web Tier Configuration check box	Select this option to skip deployment of web tier configuration in a Full Stack code pipeline. Leave the option unselected to deploy web tier configuration together with the pipeline’s code.
Pipeline	Experience Audit check box	Select this option to include an Experience Audit step in the pipeline. When enabled, the pipeline includes the Experience Audit step after the Source Code tab.

Source Code - Web Tier Config

Deploys only web tier configuration, such as Dispatcher properties used to store, process, and deliver web pages to the client. When you select Web Tier Config, Cloud Manager creates a pipeline dedicated to web tier configuration deployment.

If a full stack pipeline already exists, Cloud Manager displays a notice that creating a web tier configuration pipeline causes the existing full stack pipeline to ignore web tier configuration. After you create the web tier configuration pipeline, Cloud Manager manages web tier configuration deployments through that pipeline instead of the full stack pipeline.

table 0-row-3 1-row-3 2-row-3 3-row-3
Section	Option	Description
Source code	Repository	From the drop-down list, select the Git repository that contains the web tier configuration.
	Git Branch	Select the branch in the chosen repository that Cloud Manager uses for the deployment. If necessary, click Refresh to update the list of available branches for the selected repository. Use this option if a recently created branch does not appear in the list.
	Code Location	Enter the path in the selected repository that contains the web tier configuration to deploy. The default location is the repository root (`/`).

Click Save.

About using Smart Build in a non-production pipeline about-smart-build

Smart Build in Cloud Manager is an optimized build strategy for non-production pipelines. Smart Build reduces build times by caching modules and rebuilding only those modules that have changed since the last successful run. Unchanged modules are reused from cache, while only modified modules and their dependencies are rebuilt, improving efficiency for iterative development workflows.

Smart Build is currently available only for the following:

Code Quality pipelines.
Dev full-stack deployment pipelines.

NOTE

The first run after enabling Smart Build behaves like a Full Build because the cache is empty.

Smart Build is recommended when you have the following:

You are actively developing and committing frequent incremental changes.
Your project contains multiple Maven modules.
Full builds are taking significant time.

Smart Build is not always ideal when you have the following:

Your build relies heavily on plugins that perform operations outside Maven’s dependency graph.
You require full rebuild validation on every execution.

Understand build performance smart-build-performance

The performance gain from using Smart Build depends on several factors including the following:

The number of modules in the project.
The frequency and scope of code changes.
The distribution of dependencies across modules.

Generally, projects with many independent modules can see the greatest improvement.

Per-module cache opt-out smart-build-cache-optout

Smart Build provides fine-grained control that lets you disable caching for specific modules. This ability is useful when certain modules:

Use plug-ins, such as exec-maven-plugin or maven-antrun-plugin.
Perform file operations not tracked by Maven dependencies.
Produce inconsistent results when cached.

Disable caching for a module smart-build-disable-caching

You can add the following property to the affected module’s pom.xml:

<properties>
  <maven.build.cache.enabled>false</maven.build.cache.enabled>
</properties>

This syntax forces the module to rebuild on every pipeline execution while other modules continue to benefit from caching.

Limitations and considerations when using Smart Build smart-build-limitations

Keep the following in mind when you use Smart Build:

Smart Build relies on Maven dependency analysis.
Changes outside the dependency graph may not trigger rebuilds.
Some plug-ins may not be fully compatible with caching.
You can switch back to Full Build at any time by editing the non-production pipeline.

If you encounter unexpected build behavior, consider disabling caching for specific modules or temporarily switching your build strategy to Full Build.

Troubleshooting Smart Build issues smart-build-troubleshoot

Issue

The next steps the-next-steps

After you configure the pipeline, you can deploy your code. See Code Deployment for more details.

Video tutorial video-tutorial

This video provides an overview of the pipeline creation process, which is detailed in this document.

https://video.tv.adobe.com/v/26316/?learn=on

recommendation-more-help

experience-manager-cloud-manager-help-main-toc