Learn how to deploy your code to Production using Cloud Manager pipelines in AEM as a Cloud Service.
Deploying code seamlessly to Stage and then through to Production is done via a Production pipeline. The Production pipeline execution is broken into two logical phases.
Only the Full Stack Code pipeline type supports code scanning, function testing, UI testing, and experience audit.
Once you have configured your production Pipeline including repository, environment, and testing environment, you are ready to deploy your code.
Log into Cloud Manager at my.cloudmanager.adobe.com and select the appropriate organization.
Click the program for which you want to deploy code.
Click Deploy from the call-to-action on the Overview screen to start the deployment process.
The Pipeline Execution screen displays. Click Build to start the process.
The build process deploys your code through three phases.
You can review the steps from various deployment processes by viewing logs, or reviewing results, for the testing criteria.
The Stage Deployment phase. involves these steps.
The Stage testing phase involves these steps.
Product Functional Testing - Cloud Manager pipeline executes tests that run against the stage environment.
Custom Functional Testing - This step in the pipeline is always executed and cannot be skipped. If no test JAR is produced by the build, the test passes by default.
Custom UI Testing - This step is an optional feature that automatically run UI tests created for custom applications.
Experience Audit - This step in the pipeline is always executed 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 process for deploying to production topologies differs slightly to minimize impact visitors to an AEM site.
Production deployments generally follow the same steps as previously described, but in a rolling manner.
This process continues until the deployment has reached all publishers and dispatchers in the topology.
The following steps will timeout if left waiting for user feedback:
Step | Timeout |
---|---|
Code Quality Testing | 14 days |
Security Testing | 14 days |
Performance Testing | 14 days |
Application for Approval | 14 days |
Schedule Production Deployment | 14 days |
CSE Support | 14 days |
All Cloud Service deployments follow a rolling process to ensure zero downtime. See How Rolling Deployments Work to learn more.
The Dispatcher cache is wiped out on each deployment. It is subsequently warmed up before the new publish nodes accept traffic.
In rare cases, production deployment steps may fail for transient reasons. In such cases, re-execution of the production deployment step is supported so long as the production deployment step has completed, regardless of the type of completion (for example, cancelled or unsuccessful). Re-execution creates a new execution using the same pipeline consisting of three steps.
In such circumstances where a re-execution is possible, the production pipeline status page provides the Re-execute option next to the usual Download build log option.
In a re-execution, the build step is labeled in the UI to reflect that it is copying artifacts, not re-building.
In addition to being available in the UI, you can use the Cloud Manager API to trigger re-executions as well as identify executions that were triggered as re-executions.
To trigger a re-execution, make a PUT request to the HAL Link https://ns.adobe.com/adobecloud/rel/pipeline/reExecute
on the production deploy step state.
This link is only available for the production deploy step.
{
"_links": {
"https://ns.adobe.com/adobecloud/rel/pipeline/logs": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/logs",
"templated": false
},
"https://ns.adobe.com/adobecloud/rel/pipeline/reExecute": {
"href": "/api/program/4/pipeline/1/execution?stepId=2983530",
"templated": false
},
"https://ns.adobe.com/adobecloud/rel/pipeline/metrics": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/metrics",
"templated": false
},
"self": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530",
"templated": false
}
},
"id": "6187842",
"stepId": "2983530",
"phaseId": "1575676",
"action": "deploy",
"environment": "weretail-global-b75-prod",
"environmentType": "prod",
"environmentId": "59254",
"startedAt": "2022-01-20T14:47:41.247+0000",
"finishedAt": "2022-01-20T15:06:19.885+0000",
"updatedAt": "2022-01-20T15:06:20.803+0000",
"details": {
},
"status": "FINISHED"
The syntax of the HAL link’s href value is only an example. The actual value should always be read from the HAL link and not generated.
Submitting a PUT request to this endpoint results in a 201 response if successful, and the response body is the representation of the new execution. This is similar to starting a regular execution through the API.
Re-executed executions can be identified by the value RE_EXECUTE
in the trigger
field.