Learn about Cloud Manager’s CI/CD pipelines and how they can be used to efficiently deploy your code.
A CI/CD pipeline in Cloud Manager is a mechanism to build code from a source repository and deploy it to an environment. A pipeline can be triggered by an event, such as a pull request from a source code repository (that is, a code change), or on a regular schedule to match a release cadence.
To configure a pipeline, you must:
Cloud Manager offers two types of pipelines:
For a quick overview of pipeline types, view this short video.
A production pipeline is a purpose-built pipeline that includes a series of orchestrated steps to deploy source code for production use. The steps include first building, packaging, testing, validating, and deploying into all staging environments. Therefore a production pipeline can only be added once a set of production and staging environments is created.
See Configuring a Production Pipeline for more details.
A non-production pipeline mainly serves to run code quality scans or to deploy source code to a development environment.
See Configuring a Non-Production Pipeline for more details.
In addition to production and non-production, pipelines can be differentiated by the type of code they deploy.
These are described in detail later in this document.
The following table summarizes all of the pipelines available in Cloud Manager and their usages.
Pipeline Type | Deployment or Code Quality | Source Code | Purpose | Notes |
---|---|---|---|---|
Production or Non-Production | Deployment | Full-Stack | Simultaneously deploys back-end and front-end code builds along with HTTPD/Dispatcher configurations | When front-end code must be deployed simultaneously with AEM server code. When front-end pipelines or web tier config pipelines have not yet been adopted. |
Production or Non-Production | Deployment | Front-End | Deploys front-end code build containing one or more client-side UI application | Supports multiple, concurrent front-end pipelines Much faster than full-stack deployments |
Production or Non-Production | Deployment | Web Tier Config | Deploys HTTPD/Dispatcher configurations | Deploys in minutes |
Non-Production | Code Quality | Full-Stack | Runs code quality scans on full-stack code without a deployment | Supports multiple pipelines |
Non-Production | Code Quality | Front-End | Runs code quality scans on front-end code without a deployment | Supports multiple pipelines |
Non-Production | Code Quality | Web Tier Config | Runs code quality scans on dispatcher configurations without a deployment | Supports multiple pipelines |
The following diagram illustrates Cloud Manager’s pipeline configurations with traditional, single front-end repository, or independent front-end repository setups.
Full-stack pipelines deploy back-end code, front-end code, and web tier configurations to AEM runtime all at the same time.
The full-stack pipeline represents an ‘uber’ pipeline, doing everything at once, while giving users the options to exclusively deploy their front-end code or Dispatcher configurations via the front-end pipeline and the web tier config pipelines respectively.
Full-stack pipelines package front-end code (JavaScript/CSS) as AEM client libraries.
Full-stack pipelines may deploy web tier configurations if a web tier config pipeline is not configured.
The following restrictions apply.
In addition, be aware of how the full-stack pipeline behaves if you choose to introduce a web tier config pipeline.
Full-stack pipelines can be code quality pipelines or deployment.
Front-end code is any code that is served as a static files. It is separate from UI code served by AEM and may include site themes, customer-defined SPAs, SPAs, and other solutions.
Front-end pipelines help your teams streamline your design and development process by enabling accelerated deployment of front-end code asynchronous of back-end development. This dedicated pipeline deploys JavaScript and CSS to the AEM distribution layer as a theme, resulting in a new theme version which may be referenced from pages delivered by AEM.
You must be on AEM version 2021.10.5933.20211012T154732Z
or higher with AEM Sites enabled to use front-end pipelines.
A user with the Deployment Manager role can create and run multiple front-end pipelines concurrently.
There is, however, a maximum limit of 300 pipelines per program (across all types).
Front-end pipelines can be code quality pipelines or deployment pipelines.
Before you configure front-end pipelines, review the AEM Quick Site Creation Journey for an end-to-end guide through the easy-to-use AEM Quick Site Creation tool. This journey will help you streamline your front-end development and allow you to quickly customize your site with no back-end AEM knowledge.
To learn how to configure front-end pipelines, see the following:
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.
To learn how to configure full-stack pipelines, see the following documents:
Web tier config pipelines enable exclusive deployment of HTTPD/Dispatcher configuration to the AEM runtime by decoupling it from other code changes. It a streamlined pipeline that provides users who wish to only deploy dispatcher configuration changes, an accelerated means to do so in only a few minutes.
With web tier config pipelines, you can choose between storing your web config in the same source location as for the full stack pipeline or in a different location, depending which structure better suits your project.
The following restrictions apply.
2021.12.6151.20211217T120950Z
or newer to use web-tier config pipelines.In addition, be aware of how the full stack pipeline behaves when introducing a web tier pipeline.
Web tier config pipelines can be of the type code quality or deployment.
To learn how to configure web tier config pipelines, see the following documents: