Configuring Non-Production Pipelines

Learn how to configure non-production pipelines to test the quality of your code before deploying to production environments.

A user must have the Deployment Manager role to configure non-production pipelines.

Non-Production Pipelines

In addition to production pipelines which deploys to stagings and production environments, you can also set up non-production pipelines to validate your code.

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 - In addition to executing the build and code quality steps like the code quality pipelines, these pipelines deploy the code to a non-production environment.

Adding a New Non-Production Pipeline

Once you have set up your program and have at least one environment using the Cloud Manager UI, you are ready to add a non-production pipeline by following these steps.

1. Log into Cloud Manager at my.cloudmanager.adobe.com and select the appropriate organization and program.

2. Access the Pipelines card from the Cloud Manager home screen. Click +Add and select Add Non-Production Pipeline.

   

3. On the Configuration tab of the Add Non-Production Pipeline dialog, select the type of non-production pipeline you with to add.

   • Code Quality Pipeline - Create a pipeline that builds your code, runs unit tests, and evaluates code quality but does NOT deploy.
   • Deployment Pipeline - Create a pipeline that builds your code, runs unit tests, evaluates code quality, and deploys to an environment.

   

4. Provide a Non-Production Pipeline Name to identify your pipeline along with the following additional information.

   • Deployment Trigger - You have the following options when defining the deployment triggers to start the pipeline.

     • Manual - Use this option to manually start the pipeline.
     • On Git Changes - This option 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.

5. If you choose to create a Deployment Pipeline, you must also define the 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 is essentially emulating a user manually rejecting each failure.
   • Continue Immediately - If selected, the pipeline procedes automatically whenever an important failure occurs. It is essentially emulating a user manually approving each failure.

6. Click Continue.

7. On the Source Code tab of the Add Non-Production Pipeline dialog, you must select which type of code the pipeline should process.

   • Full Stack Code
   • Targeted deployment

See CI/CD Pipelines for more information about the types of pipelines.

The steps to complete the creation of your non-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.

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 finish the configuration of the full-stack code non-production pipeline, follow these steps.

1. On the Source Code tab, you must define the following options.

   • Eligible Deployment Environments - If your pipeline is a deployment pipeline, you must select to which environments it should deploy.
   • Repository - This option defines from which git repo that the pipeline should retrieve the code.
   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 helps you find the matching branches that you can select.

   • Ignore Web Tier Configuration - When checked, the pipeline does not deploy your web tier configuration.

   • Pipeline - If your pipeline is a deployment pipeline, you can choose to run a testing phase. Check the options that you want to enable in this phase. If none of the options are selected, the testing phase is not displayed during the pipeline’s run.

     • Product Functional Testing - Execute product functional tests against the development environment.
     • Custom Functional Testing - Execute custom functional tests against the development environment.
     • Custom UI Testing - Execute custom UI tests for custom applications.
     • Experience Audit - Execute Experience Audit

   

2. Click Save.

The pipeline is saved and you can now manage your pipelines on the Pipelines card on the Program Overview page.

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 on your AEM environment, maintenance tasks, CDN rules, and more.
  • See the document Traffic Filter Rules including WAF Rules to learn how to manage traffic filter rules in your repository so they are deployed properly.
• 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.

The steps to complete the creation of your non-production, targeted deployment pipeline are the same once you choose a deployment type.

1. Choose which deployment type you require.

1. Define the Eligible Deployment Environments.

   • If your pipeline is a deployment pipeline, you must select to which environments it should deploy.

2. Under Source Code, define the following options:

   • Repository - This option defines from which git repo that the pipeline should retrieve the code.
   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.

   

3. Click Save.

The pipeline is saved and you can now manage your pipelines on the Pipelines card on the Program Overview page.

When running a targeted deployment pipeline, configurations such as WAF configurations will be deployed, provided they are saved to environment, repository, and branch you defined in the pipeline.

Skip Dispatcher Packages

If you want Dispatcher packages built as part of your pipeline, but do not want them published to build storage, you can disable publishing them, which may reduce pipeline run duration.

The following configuration to disable publishing Dispatcher packages must be added via your project pom.xml file. It is based on an environment variable, which serves as a flag you can set in the Cloud Manager build container to define when Dispatcher packages should be ignored.

<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>