Learn how to deploy your code and what happens in Cloud Manager when you do.
Once you have configured your production pipeline including the necessary repository and environments, 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 build process starts the code deployment process including the following steps:
You can review the steps from various deployment processes by viewing logs, or reviewing results, for the testing criteria.
A number of actions occur during each step of the deployment, which are described in this section. See the section Deployment Process Details for technical details of how the code itself is deployed behind-the-scenes.
The Stage deployment step includes the following actions:
The Stage testing step includes the following actions:
Security Testing: This step evaluates the security impact of your code on the AEM environment. See the document Understanding Test Results for details on the testing process.
The Production Deployment step, includes the following actions:
Once your deployment is complete, your code is in its targeted environment and you can view the logs.
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 |
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.
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.
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 the Run Modes section of the document Deploying to AEM as a Cloud Service.
The dispatcher artifact is deployed to each dispatcher as follows:
httpd
directory. 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 can not 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 staging Deployments, i.e. for development environment, detach and attach steps in both non-production pipelines, and for staging environment the production pipeline.
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:
This process continues until the deployment has reached all publishers and dispatchers in the topology.
In critical situations, Adobe Managed Services customers may need to deploy code changes to their stage and production environments without waiting for a full Cloud Manager test cycle to execute.
To address these situations, the Cloud Manager production pipeline may be executed in an emergency mode. When this mode is used, the security and performance test steps are not executed. All other steps, including any configured approval steps, are executed as in the normal pipeline execution mode.
The emergency pipeline execution mode feature is activated on a program-by-program basis by the Customer Success Engineers.
When starting a production pipeline execution, if the emergency pipeline execution mode feature has been activated for the program, you can start the execution in either normal or emergency mode from a dialog box.
When viewing the pipeline execution details page for an execution run in emergency mode, the breadcrumbs at the top of the screen show an indicator that the pipeline is executing in emergency mode.
Executing a pipeline in emergency mode can also be done through the Cloud Manager API or CLI. To start an execution in emergency mode, submit a PUT
request to the pipeline’s execution endpoint with the query parameter ?pipelineExecutionMode=EMERGENCY
or, when using the CLI:
$ aio cloudmanager:pipeline:create-execution PIPELINE_ID --emergency
Re-execution of the production deployment step is available for executions where the production deploy step has completed. The type of completion is not important. The deployment could be successful (only for AMS programs), cancelled, or unsuccessful. The primary use case is where the production deployment step failed for transient reasons. Re-execution creates a new execution using the same pipeline. This new execution consists of three steps:
The build step may be labeled differently in the UI to reflect that it is copying artifacts, not re-building.
To identify if an execution is a re-execute execution, the trigger
field can be examined. Its value will be RE_EXECUTE
.
To trigger a re-execution, a PUT
request needs to be made to the HAL Link http://ns.adobe.com/adobecloud/rel/pipeline/reExecute
on the production deploy step state. If this link is present, the execution can be restarted from that step. If it is absent, the execution can not be restarted from that step. This link will only ever be present on the production deploy step
{
"_links": {
"http://ns.adobe.com/adobecloud/rel/pipeline/logs": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/logs",
"templated": false
},
"http://ns.adobe.com/adobecloud/rel/pipeline/reExecute": {
"href": "/api/program/4/pipeline/1/execution?stepId=2983530",
"templated": false
},
"http://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 not intended to be used as a point of reference. The actual value should always be read from the HAL link and not generated.
Submitting a PUT
request to this endpoint will result in a 201
response if successful and the response body will be the representation of the new execution. This is similar to starting a regular execution through the API.