Azure Web App Deployment Rollback

Updated 2 months ago by Michael Cretzman

Currently, this feature is behind the Feature Flag AZURE_WEBAPP. Contact Harness Support to enable the feature.

Harness performs rollback on failed Azure Web App deployments.

In this topic:

Limitations

Rollback Limitations for both Azure Container and Non-Containerized Rollbacks

For Non-Containerized artifacts deployments, see Add Non-Containerized Artifacts for Azure Web App Deployment.
  • Harness Post-Deployment Rollback: to see if Post-Production Rollback is supported for Azure Web App deployments, see Rollback Production Deployments.
  • Rollback only restores the state of the stage slot. If a step that follows the Swap Slot step fails, such as a failed Approval or Shell Script step, Harness only rolls back the stage slot. The target slot is not changed.

Rollback Limitations for Non-Containerized Rollbacks

Rollback for Non-Containerized artifact deployments is not supported for the first two deployments because the necessary artifact details are not available to perform a rollback.

Streaming Logs Limitations for both Azure Container and Non-Containerized Deployments

You might face timeout issues as a result of limitations with streaming Web App slot deployment logs. For example, you might see java.net.SocketTimeoutException: timeout or some other socket errors as a result of the Azure SDK client.

Harness is working with the Azure team for a resolution (see issue 27221). At this time, you can use a Harness HTTP step to verify that the slot is up and ready.

Rollback Summary

For Azure Web App deployments, Harness saves the previous Docker or non-containerized app details that were running on the slot.

In case of an Azure Web App deployment failure, Harness rollback redeploys the previous instance.

Slot Rollback

Harness initially deploys to the source (staging) slot and then swaps slots with the target (production) slot.

As the source slot is the slot is where Harness deploys the new Web App version, Harness rolls back the app version in the source slot only.

Harness does not rollback the app version in the target slot.

Traffic Rollback

Harness returns all traffic to the previous, pre-deployment percentages.

If the pre-deployment traffic was arranged with the source slot at 20% and the target slot at 80%, rollback will return network traffic to these percentages.

Rollback Example for Non-Containerized Rollbacks

Here's an example of a rollback.

Update Slot Configuration Settings:

Deploy to Slot:

Rollback Logs

Here's the log activity from a rollback with the timestamps removed:

Sending request for stopping deployment slot - [stage]
Operation - [Stop Slot] was success
Request sent successfully

Start updating Container settings for slot - [stage]
Start cleaning existing container settings

Current state for deployment slot is - [Stopped]
Deployment slot stopped successfully

Start updating application configurations for slot - [stage]
Deployment slot configuration updated successfully

Existing container settings deleted successfully
Start cleaning existing image settings

Existing image settings deleted successfully
Start updating Container settings:
[[DOCKER_REGISTRY_SERVER_URL]]

Container settings updated successfully
Start updating container image and tag:
[library/nginx:1.19-alpine-perl], web app hosting OS [LINUX]

Image and tag updated successfully for slot [stage]
Deployment slot container settings updated successfully

Sending request for starting deployment slot - [stage]
Operation - [Start Slot] was success
Request sent successfully

Sending request to shift [0.00] traffic to deployment slot: [stage]

Current state for deployment slot is - [Running]
Deployment slot started successfully

Traffic percentage updated successfully

The following task - [SLOT_ROLLBACK] completed successfully

See Also


How did we do?