Skip to main content

Deployment Strategy: Blue/Green with Azure Deployment Slots

Overview​

Production deployments use Azure App Service deployment slots for zero-downtime deploys with automatic rollback capability.

Architecture​

                    ┌─────────────────┐
                    │   GitHub Push    │
                    │   to master      │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │  Build & Test   │
                    │  (backend +     │
                    │   frontend)     │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │  Pre-deploy     │
                    │  DB Backup      │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │  Run DB         │
                    │  Migrations     │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │  Deploy to      │
                    │  STAGING slot   │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │  Health Check   │
                    │  /health/ready  │──── FAIL ──→ Abort (staging only affected)
                    └────────┬────────┘
                             │ PASS
                    ┌────────▼────────┐
                    │  Slot Swap      │
                    │  staging ↔ prod │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │  Verify Prod    │
                    │  Health Check   │──── FAIL ──→ Auto-Rollback (swap back)
                    └────────┬────────┘
                             │ PASS
                    ┌────────▼────────┐
                    │  Smoke Tests    │
                    └────────┬────────┘
                             │
                          DONE

Prerequisites​

  • App Service Plan: S1 tier or higher (B1 does not support deployment slots)
  • Staging slot created via infra/setup-azure-resources.sh prod
  • Staging slot inherits production configuration (connection strings, app settings)

How It Works​

1. Deploy to Staging​

The new code is deployed to the staging slot. Production traffic is unaffected.

2. Health Check Staging​

The pipeline checks /health/ready on the staging slot URL. If staging is unhealthy, the deployment is aborted without touching production.

3. Slot Swap​

Azure performs an atomic swap of the staging and production slots. This is near-instant (typically <5 seconds) because:

  • The staging instance is already warmed up
  • Azure swaps the VIP routing, not the actual instances

4. Verify Production​

After the swap, the pipeline verifies production health. If production is unhealthy:

  • Automatic rollback: The pipeline swaps the slots back
  • The previous version (now in staging) is restored to production

5. Smoke Tests​

Critical endpoints are tested to ensure the deployment is working.

Manual Rollback​

If issues are discovered after deployment:

# Swap back to previous version
az webapp deployment slot swap \
  --name hcss-eventscore-api-prod \
  --resource-group hcss-rg-prod \
  --slot staging \
  --target-slot production

Database Migrations​

Migrations run BEFORE the slot swap, against the production database. This means:

  • Migrations must be backward-compatible (both old and new code must work with the new schema)
  • Additive changes only (new tables, new columns with defaults)
  • Column renames or deletions should be done in a follow-up release after the old code is fully removed

Frontend Deployments​

Frontend is deployed to Azure Static Web Apps, which has its own staging preview environment. The frontend deployment is independent of the backend blue/green process.

Slot Configuration​

Slot-sticky settings (different per slot):

  • ASPNETCORE_ENVIRONMENT can differ (e.g., staging slot could use "Staging")

Shared settings (same across slots):

  • Database connection strings
  • Key Vault references
  • SendGrid API keys