Rollback returns a deployment to the last known good state when health signals, metrics, or production behavior show that the new version should not proceed. It can abort a deployment before wider traffic exposure or restore the previous behavior after release. section 9.3.4 section 9.3.5
A practical rollback workflow can:
- Wait for the new deployment to report readiness through a health endpoint before testing it. section 9.3.4
- Monitor liveness or other health signals while moving traffic gradually to the new version. section 9.3.4
- Compare metrics such as memory usage with the known-good deployment profile and abort or revert when anomalies appear. section 9.3.4
- Disable a feature toggle to show the old implementation again without uninstalling the deployed software. section 9.3.5
Listing 9.9 Checking the health status
- name: ensure deployment is healthy before we test
run: |
HEALTH_ENDPOINT="https://${{stagingurl}}/health/ready"
while true; do
response=$(curl -s "$HEALTH_ENDPOINT")
status=$(echo "$response" | jq -r '.status')
if [[ "$status" == "Healthy" ]]; then
echo "Health endpoint current status :" $status
break
fi
echo "Waiting for health endpoint..."
sleep 1
done
env:
homepage: ${{ needs.deploy.outputs.homepage }}
Use the health-check listing to gate deployment testing until the ready endpoint returns a Healthy status. section 9.3.4
Feature-toggle rollback
Deploy the new implementation while keeping its feature toggle off. Validate the deployment and then expose the feature gradually. If the new behavior degrades production, switch the toggle off to restore the old implementation. section 9.3.5
