�۶���Ƶ

Code deployment code-deployment

Learn how to deploy your code and what happens in Cloud Manager when you do.

Deploy code with Cloud Manager deploying-code-with-cloud-manager

Once you have configured your production pipeline, including the necessary repository and environments, you are ready to deploy your code.

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.

Deployment steps deployment-steps

A number of actions occur during each step of the deployment, which is described in this section. See Deployment Process Details for technical details of how the code itself is deployed behind-the-scenes.

Stage deployment step stage-deployment

The Stage deployment step includes the following actions:

Stage testing step stage-testing

The Stage testing step includes the following actions:

Production deployment step production-deployment

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.

Timeouts timeouts

The following steps time out if left waiting for user feedback:

Deployment process details deployment-process

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:

Deployment to production phase deployment-production-phase

The process for deploying to production topologies differs slightly 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.

Emergency pipeline execution mode emergency-pipeline

In critical situations, �۶���Ƶ Managed Services customers might need to deploy code changes to their stage and production environments immediately. This ability lets them bypass the full Cloud Manager test cycle.

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.

Use emergency pipeline execution mode using-emergency-pipeline

When you start a production pipeline execution, you can choose between normal or emergency mode from a dialog box. This option is available if the emergency pipeline execution mode feature is activated for the program. This choice is available once the feature is enabled.

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-executing a production deployment reexecute-deployment

In rare cases, production deployment steps may fail for transient reasons. In these cases, you can re-execute the production deployment step as long as it was completed, regardless of whether it was successful, canceled, or unsuccessful. Re-execution is supported by using the same pipeline that consists of the following 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.

Limitations limitations

Re-execute API reexecute-api

In addition to being available in the UI, you can use to trigger re-executions and identify executions that were triggered as re-executions.

Trigger a re-execution triggering

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.

This link is only ever available for 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 only an example and 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. The response body is the representation of the new execution. This functionality is similar to starting a regular execution through the API.

Identify a re-executed execution identifying

The system identifies re-executed executions by the value RE_EXECUTE in the trigger field.