Add a production pipeline configure-production-pipeline
Learn how to configure production pipelines to build and deploy your code to production environments. A production pipeline deploys code first to the stage environment. On approval, it deploys the same code to the production environment.
A user must have the Deployment Manager role to configure production pipelines.
- The program is created.
- The Git repository has at least one branch.
- The production and staging environments are created.
Before you start to deploy your code, configure your pipeline settings from the Cloud Manager.
Add a new production pipeline adding-production-pipeline
After you have set up your program and have at least one environment using the Cloud Manager UI, you are ready to add a production pipeline by following these steps.
-
Sign into Cloud Manager at experience.adobe.com.
-
In the Quick access section, click Experience Manager.
-
In the left side panel, click Cloud Manager.
-
Select an organization that you want.
-
On the My Programs console, click a program.
-
On the My Programs console, select the program.
-
Navigate to the Pipelines card from the Program Overview page and click Add to select Add Production Pipeline.
-
The Add Production Pipeline dialog box displays. Provide a Pipeline Name to identify your pipeline along with the following options. Click Continue.
Deployment Trigger - You have the following options when defining the deployment triggers to start the pipeline.
- Manual - Start the pipeline manually.
- On Git Changes - Starts the CI/CD pipeline whenever commits are added to the configured Git branch. With this option, you can still start the pipeline manually as required.
Important Metric Failures Behavior - During pipeline setup or edit, the Deployment Manager has the option of defining the behavior of the pipeline when an important failure is encountered in any of the quality gates. The available options are:
- Ask every time - Default setting. It requires manual intervention in any important failure.
- Fail Immediately - If selected, the pipeline is canceled whenever an important failure occurs. This process is essentially emulating a user manually rejecting each failure.
- Continue Immediately - If selected, the pipeline proceeds automatically whenever an important failure occurs. This process is essentially emulating a user manually approving each failure.
-
On the Source Code tab, select which type of code the pipeline should process.
See CI/CD Pipelines for more information about the types of pipelines.
The steps to complete the creation of your production pipeline vary depending on the type of source code you selected. Follow the links above to jump to the next section of this document so you can complete the configuration of your pipeline.
I am using a Full Stack Code full-stack-code
A full-stack code pipeline simultaneously deploys back-end and front-end code builds containing one or more AEM server applications along with HTTPD/Dispatcher configuration.
To configure a full stack code pipeline:
-
On the Source Code tab, define the following options.
- Repository - Defines from which Git repository that the pipeline should retrieve the code.
note tip TIP See Add and Manage Repositories to learn how to add and manage repositories in Cloud Manager. -
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.note important IMPORTANT Smart Build is available only for Code Quality pipelines and Dev Full Stack Code deployment pipelines. * **Ignore Web Tier Configuration** - When checked, the pipeline does not deploy your web tier configuration.
-
-
Pause before deploying to Production - Pauses the pipeline before deploying to production.
-
Scheduled - Lets the user enable the scheduled production deployment.
-
Click Continue to advance to the Experience Audit tab where you can define the paths that should always be included in the Experience Audit.
-
Provide paths to be included in the Experience Audit.
- See Experience Audit Testing for details.
-
Click Save to save your pipeline.
When the pipeline runs, paths configured for the Experience Audit are submitted and evaluated based on performance, accessibility, SEO, best practices, and PWA tests. For more details, see Understanding Experience Audit Results.
The pipeline is saved and you can now manage your pipelines on the Pipelines card on the Program Overview page.
I am using Targeted deployment targeted-deployment
A targeted deployment deploys code only for selected parts of your AEM application. In such a deployment, you can choose to Include one of the following types of code:
-
Config - Configure settings for various features in your AEM environment.
- See Using Config Pipelines for a list of supported configurations, which include log forwarding, purge-related maintenance tasks, and various CDN configurations, and to manage them in your repository so they are deployed properly.
- When running a targeted deployment pipeline, configurations are deployed, provided they are saved to the environment, repository, and branch defined in the pipeline.
- At any time, there can only be one config pipeline per environment.
-
Configure Edge Delivery Services config pipeline - Edge Delivery Configuration Pipelines do not have separate development, staging, and production environments. In AEM as a Cloud Service, changes move through development, stage, and production tiers. In contrast, an Edge Delivery Configuration Pipeline applies its configuration directly to all Edge Delivery Sites domains registered in Cloud Manager. To learn more, see Add an Edge Delivery Pipeline.
-
Front End Code - Configure JavaScript and CSS for the front end of your AEM application.
- With front-end pipelines, more independence is given to front-end developers and the development process can be accelerated.
- See the document Developing Sites with the Front-End Pipeline for how this process works along with some considerations to be aware of to get the full potential out of this process.
-
Web Tier Config - Configure Dispatcher properties to store, process, and delivery web pages to the client.
- See the document CI/CD Pipelines for more details.
- If a web-tier code pipeline exists for the selected environment, this selection is disabled.
- If you create a web tier config pipeline for an environment with an existing full-stack pipeline, the web tier configuration in the full-stack pipeline is ignored. This change affects only the web tier configuration in that environment.
To configure a targeted deployment pipeline:
- Choose which deployment type you require.
-
Define the Eligible Deployment Environments.
- If your pipeline is a deployment pipeline, you must select to which environments it should deploy.
-
Under Source Code, define the following options:
- Repository - This option defines from which git repo that the pipeline should retrieve the code.
note tip TIP See Adding and Managing Repositories so you can learn how to add and manage repositories in Cloud Manager. - Git Branch - This option defines from which branch in the selected pipeline should retrieve the code.
- Enter the first few characters of the branch name and the auto-complete feature of this field. It finds the matching branches that you can select.
- Code Location - This option defines the path in the branch of the selected repo from which the pipeline should retrieve the code.
- Pause before deploying to Production - This option pauses the pipeline before deploying to production.
- Scheduled - Lets the user enable the scheduled production deployment. Only available for web tier targeted deployments.
-
Click Save.
The pipeline is saved and you can now manage your pipelines on the Pipelines card on the Program Overview page.
BETA: About using Smart Build in a production pipeline about-smart-build-production-pipeline
Smart Build in Cloud Manager is an optimized build strategy for 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 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-pluginormaven-antrun-plugin. - Perform file operations not tracked by Maven dependencies.
- Cached content produces inconsistent results.
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 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
• Verify plug-in behavior (especially
exec/antrun plug-ins).• Check if most modules are changing frequently.
• Use Full Build for verification.
See Add a production pipeline to enable Smart Build.
Skip Dispatcher packages skip-dispatcher-packages
To build Dispatcher packages in your pipeline without publishing them to build storage, you can disable the publishing option. Doing so may help reduce the pipeline’s run time.
The following configuration to disable publishing Dispatcher packages must be added via your project pom.xml file. An environment variable serves as a flag that you set in the Cloud Manager build container to determine when to ignore Dispatcher packages.
<profile>
<id>only-include-dispatcher-when-it-isnt-ignored</id>
<activation>
<property>
<name>env.IGNORE_DISPATCHER_PACKAGES</name>
<value>!true</value>
</property>
</activation>
<modules>
<module>dispatcher</module>
</modules>
</profile>