Configuring Non-Production Pipelines 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 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.
NOTE
You can edit pipeline settings after the initial setup.

Adding a New Non-Production Pipeline adding-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.

On the My Programs screen, select the program.

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

    Add non-production pipeline

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

    Add Non-Production pipeline dialog

  3. 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.
  4. 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.
  5. Click Continue.

  6. On the Source Code tab of the Add Non-Production Pipeline dialog, you must 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 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 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.

NOTE
If a full-stack code pipeline exists for the selected environment, this selection is disabled.

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

    Full-stack pipeline

  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 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 traffic filter rules on your AEM environment.

    • 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.
    • 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.
    • At any time, there can only be one config pipeline per environment.
  • 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 have an existing full-stack pipeline deploying to an environment, creating a web tier config pipeline for the same environment will case the existing web tier configuration in the full-stack pipeline to be ignored.

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.

Targeted deployment options

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

    Config pipeline

  3. Click Save.

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

Skip Dispatcher Packages 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>
recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab