Configuring a Production Pipeline

Learn how to configuring Production pipelines to build and deploy your code to Production environments. A Production pipeline deploys code first to Stage environment, and upon approval deploys the same code to the Production environment.

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

NOTE

A production pipelinecannot be set up until program creation is complete, a git repository has at least one branch, and a production and staging environment set is created.

Before you start to deploy your code, you must configure your pipeline settings from the Cloud Manager.

NOTE

You can edit pipeline settings after the initial setup.

Adding a New 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 production pipeline by following these steps.

TIP

Before you configure a front-end pipeline, see the AEM Quick Site Creation Journey for an end-to-end guide though the easy-to-use AEM Quick Site Creation tool. This journey will help you streamline the front-end development of your AEM Site, allowing you to quickly customize your site with no AEM back-end knowledge.

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

  2. Navigate to the Pipelines card from the Program Overview page and click on Add to select Add Production Pipeline.

    The Pipelines card on the Program Manager overview

  3. 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 - Use this option to manually start the pipeline.
    • On Git Changes - This options 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 - This is the default setting and requires manual intervention on any important failure.
    • Fail Immediately - If selected, the pipeline is cancelled whenever an important failure occurs. This is essentially emulating a user manually rejecting each failure.
    • Continue Immediately - If selected, the pipeline will proceed automatically whenever an important failure occurs. This is essentially emulating a user manually approving each failure.

    Production pipeline configuration

  4. On the Source Code tab you must define where the pipeline should retrieve its code and what type of code it is.

The steps to complete the creation of your production pipeline vary depending on the option for Source Code you selected. Follow the links above to jump to the next section of this document to complete the configuration of your pipeline.

Front End Code

A front-end code pipeline deploys front-end code builds containing one or more client-side UI applications. See the document CI/CD Pipelines for more information about this type of pipeline.

To finish the configuration of the front end code production pipeline, follow these steps.

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

    • Repository - This option defines from which git repo the pipeline should retrieve the code.
    TIP

    See the document Adding and Managing Repositories to learn how to add and manage repositories in Cloud Manager.

    • Git Branch - This option defines from which branch in the selected the pipeline should retrieve the code.
      • Enter the first few characters of the branch name and the auto-complete feature of this field will find the matching branches to help you 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.

    Front end code

  2. Click Save to save your pipeline.

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

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. See the document CI/CD Pipelines for more information about this type of pipeline.

NOTE

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

To finish the configuration of the full-stack code production pipeline, follow these steps.

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

    • Repository - This option defines from which git repo the pipeline should retrieve the code.
    TIP

    See the document Adding and Managing Repositories to learn how to add and manage repositories in Cloud Manager.

    • Git Branch - This option defines from which branch in the selected the pipeline should retrieve the code.
      • Enter the first few characters of the branch name and the auto-complete feature of this field will find the matching branches to help you 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 - This option allows the user to enable the scheduled production deployment.

    Full stack code

  2. Click Continue to advance to the Experience Audit tab where you can define the paths that should always be included in the Experience Audit.

    Add Experience Audit

  3. Provide a path to be included in the Experience Audit.

    • Page paths must start with /.
    • For example, if you would like to include https://wknd.site/us/en/about-us.html in the Experience Audit, enter the path /us/en/about-us.html.

    Defining a path for the Experience Audit

  4. Click Add Page and the path is auto-completed with the address of your environment and added to the table of paths.

    Saving path to the table

  5. Continue to add paths as necessary by repeating the previous two steps.

    • You can add a maximum of 25 paths.
    • If you do not define any paths, the homepage of the site is included in the Experience Audit by default.
  6. Click on Save to save your pipeline.

Paths configured for the Experience Audit are submitted to the service and evaluated according to the performance, accessibility, SEO (Search Engine Optimization), best practice, and PWA (Progressive Web App) tests when the pipeline runs. See Understanding Experience Audit Results for more details.

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

Web Tier Config

A web tier config pipeline Deploys HTTPD/Dispatcher configurations. See the document CI/CD Pipelines for more information about this type of pipeline.

To finish the configuration of the full-stack code production pipeline, follow these steps.

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

    • Repository - This option defines from which git repo the pipeline should retrieve the code.
    TIP

    See the document Adding and Managing Repositories to learn how to add and manage repositories in Cloud Manager.

    • Git Branch - This option defines from which branch in the selected the pipeline should retrieve the code.
      • Enter the first few characters of the branch name and the auto-complete feature of this field will find the matching branches to help you select.
    • Code Location - This option defines the path in the branch of the selected repo from which the pipeline should retrieve the code.
      • For web tier config pipelines this is usually the path containing conf.d, conf.dispatcher.d, and opt-in directories.
      • For example, if the project structure was generated from the AEM Project Archetype, the path would be /dispatcher/src.
    • Pause before deploying to Production - This option pauses the pipeline before deploying to production.
    • Scheduled - This option allows the user to enable the scheduled production deployment.

    Web tier code

  2. Click Save to save your pipeline.

NOTE

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 pipeline is saved and you can now manage your pipelines on the Pipelines card on the Program Overview page.

Developing Sites with the Front-End Pipeline

With front-end pipelines, more independence is given to front-end developers and the development process can be accelerated.

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

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>

On this page