Deploy your Code

Deploying Code with Cloud Manager

Once you have configured your Production Pipeline (repository, environment, and testing environment), you are ready to deploy your code.

1. Click Deploy from the Cloud Manager to start the deployment process.

   

2. The Pipeline Execution screen displays.

   Click Build to start the process.

   

3. The complete build process deploys your code.

   The following stages are involved in the build process:

   1. Stage Deployment
   2. Stage Testing
   3. Production Deployment
   NOTE

   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 Understanding the Build Environment for details on the build environment.
   • Code Scanning: This step evaluates the quality of your application code. See Understand your Test Results for details on the testing process.
   • Deploy to Stage

   

   The Stage Testing, involves the following steps:

   • Security Testing: This step evaluates the security impact of your application code on the AEM environment. See Understand your Test Results for details on the testing process.
   • Performance Testing: This step evaluates the performance of your application code. See Understand your Test Results for details on the testing process.

   

   The Production Deployment, involves the following steps:

   • Application for Approval (if enabled)
   • Schedule Production Deployment (if enabled)
   • CSE Support (if enabled)
   • Deploy to Production

   

   NOTE

   The Schedule Production Deployment is enabled while configuring the pipeline.

   Using this option, you can either schedule your production deployment or click Now to execute the production deployment immediately.

   The scheduled date and time is specified in terms of the user’s timezone.

   Click Confirm to verify your settings.

   

   Once you confirm the deployment schedule, your code deployment completes.

   The following screen displays, when Now option is selected from the above step.

   

Timeouts

The following steps will timeout if left waiting for user feedback:

Deployment Process

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:

1. Cloud Manager determines whether each artifact is an AEM or dispatcher package.

2. 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.

   

   NOTE

   This feature is expected to be primarily used by 1-1-1 customers.

3. 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.

   NOTE

   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.

4. The dispatcher artifact is deployed to each dispatcher as follows:

   1. Current configs are backed up and copied to a temporary location
   2. All configs are deleted except the immutable files. Refer to Manage your Dispatcher Configurations for more details. This clears the directories to ensure no orphaned files are left behind.
   3. The artifact is extracted to the 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 cannot be changed.
   4. Apache performs a config test. If no errors are found, the service is reloaded. If an error occurs, the configs are restored from backup, the service is reloaded, and the error is reported back to Cloud Manager.
   5. Each path specified in the pipeline configuration is invalidated or flushed from the dispatcher cache.
   NOTE

   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.

5. 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.

   NOTE

   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.

Deployment to Production Phase

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:

1. Deploy AEM packages to author.
2. Detach dispatcher1 from the load balancer.
3. Deploy AEM packages to publish1 and the dispatcher package to dispatcher1 in parallel, flush dispatcher cache.
4. Put dispatcher1 back into the load balancer.
5. Once dispatcher1 is back in service, detach dispatcher2 from the load balancer.
6. Deploy AEM packages to publish2 and the dispatcher package to dispatcher2 in parallel, flush dispatcher cache.
7. Put dispatcher2 back into the load balancer.
   This process continues until the deployment has reached all publishers and dispatchers in the topology.

Emergency Pipeline Execution Mode

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.

Using Emergency Pipeline Execution Mode

When starting a production pipeline execution, if this feature has been activated, you can start the execution in either normal or emergency mode from the dialog box, as shown in the figure below.

Additionally, viewing the pipeline execution details page for an execution run in emergency mode, the breadcrumbs at the top of the screen shows an indicator that emergency mode was used for this particular execution.

Creating a pipeline execution in this 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-Execute a Production Deployment

Re-execution of the production deployment step is supported 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. That said, the primary use case is expected to be cases 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:

1. The validate step – this is essentially the same validation that occurs during a normal pipeline execution.
2. The build step – in the context of a re-execution, the build step is copying artifacts, not actually executing a new build process.
3. The production deployment step – this uses the same configuration and options as the production deployment step in a normal pipeline execution.

The build step may be slightly differently labeled in the UI to reflect that it is copying artifacts, not re-building.

Limitations:

• Re-executing the production deployment step will only be available on the last execution.
• Re-execution is not available for rollback executions.
• If the last execution is a rollback execution, re-execution is not possible.
• If the last execution is a push update execution, re-execution is not possible.
• If the last execution failed at any point prior to the production deployment step, re-execution is not possible.

Re-Execute API

Identifying a re-execute execution

To identify if an execution is a re-execute execution, the trigger field can be examined. Its value will be RE_EXECUTE.

Triggering a new execution

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 cannot be restarted from that step. In the initial release, this link will only ever be present on the production deploy step but future releases may support starting the pipeline from other steps. Example:

 {
  "_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 above 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.