Once you have configured your Production Pipeline (repository, environment, and testing environment), you are ready to deploy your code.
Click Deploy from the Cloud Manager to start the deployment process.
The Pipeline Execution screen displays.
Click Build to start the process.
The complete build process deploys your code.
The following stages are involved in the build process:
Additionally, you can review the steps from various deployment processes by viewing logs, or reviewing results, for the testing criteria.
The Stage Deployment, involves the following steps:
Validation: This step ensures that the pipeline is configured to use the currently available resources, for example, that the configured branch exists, the environments are available.
Build & Unit Testing: This step runs a containerized build process. See Build Environment Details for details on the build environment.
Code Scanning: This step evaluates the quality of your application code. See Code Quality Testing for details on the testing process.
Build Images: This step has a log file from the process used to build images. This process is responsible for transforming the content and dispatcher packages produced by the build step into Docker images and Kubernetes configuration.
Deploy to Stage
The Stage testing, involves the following steps:
Product Functional Testing: Cloud Manager pipeline executions will support execution of tests that run against the stage environment.
Refer to Product Functional Testing for more details.
Custom Functional Testing: This step in the pipeline is always present and cannot be skipped. However, if no test JAR is produced by the build, the test passes by default.
Refer to Custom Functional Testing for more details.
Experience Audit: This step in the pipeline is always present and cannot be skipped. As a production pipeline is executed, an experience audit step is included after custom functional testing that will run the checks. The pages that are configured will be submitted to the service and evaluated. The results are informational and allow the user to see the scores and the change between the current and previous scores. This insight is valuable to determine if there is a regression that will be introduced with the current deployment.
Refer to Understanding Experience Audit results for more details.
The following section describes how AEM and dispatcher packages are deployed in the stage phase and in the production phase.
Cloud Manager uploads all target/*.zip files produced by the build process to a storage location. These artifacts are retrieved from this location during the deploy phases of the pipeline.
When Cloud Manager deploys to non-production topologies, the goal is to complete the deployment as quickly as possible and therefore the artifacts are deployed to all nodes simultaneously as follows:
Cloud Manager determines whether each artifact is an AEM or dispatcher package.
Cloud Manager removes all dispatchers from the Load Balancer to isolate the environment during the deployment.
Unless configured otherwise you can skip Load Balancer Changes in Dev and Stage Deployments, that is, detach and attach steps in both non-production pipelines, for dev environments, and the production pipeline, for stage environments.
This feature is expected to be primarily used by 1-1-1 customers.
Each AEM artifact is deployed to each AEM instance via Package Manager APIs, with package dependencies determining the deployment order.
To learn more about how you can use packages to install new functionality, transfer content between instances, and back up repository content, please refer to How to Work with Packages.
All AEM artifacts are deployed to both the author and the publishers. Run modes should be leveraged when node-specific configurations are required. To learn more about how the Run modes allow you to tune your AEM instance for a specific purpose, please refer to Run modes.
The dispatcher artifact is deployed to each dispatcher as follows:
httpddirectory. Immutable files are not overwritten. Any changes you make to immutable files in your git repository will be ignored at the time of deployment. These files are core to the AMS dispatcher framework and cannot be changed.
Cloud Manager expects the dispatcher artifact to contain the full file set. All dispatcher configuration files must be present in the git repository. Missing files or folders will result in deployment failure.
Following the successful deployment of all AEM and dispatcher packages to all nodes, the dispatchers are added back to the load balancer and the deployment is complete.
You can skip load balancer changes in development and stage deployments, that is, detach and attach steps in both non-production pipelines, for developer environments, and the production pipeline, for stage environments.
The process for deploying to production topologies differs slightly in order to minimize impact to AEM Site visitors.
Production deployments generally follow the same steps as above, but in a rolling manner: