Azure Deployment Operations

Battle-tested patterns for deploying and operating Azure services in production.

Scope: Inheritable skill. Covers SWA, Container Apps, App Service, security posture, rate limiting, production checklists, and multi-subscription management.

Azure Static Web Apps (SWA)

Environment Deployment

SWA defaults to preview environments. Always specify production explicitly:

# Anti-pattern: deploys to preview environment
swa deploy

# Correct: explicitly target production
swa deploy --env production

Rule: Every SWA deployment command in CI/CD and scripts MUST include --env production unless creating a preview intentionally.

Custom Domain Registration

Custom domains require a two-step process:

Common error: Adding CNAME but forgetting hostname registration. Both steps are required.

SWA Configuration

{
  "navigationFallback": {
    "rewrite": "/index.html",
    "exclude": ["/api/*", "/assets/*"]
  },
  "routes": [
    { "route": "/api/*", "allowedRoles": ["authenticated"] }
  ],
  "globalHeaders": {
    "X-Content-Type-Options": "nosniff",
    "X-Frame-Options": "DENY"
  }
}

Azure Container Apps

Health Probe Configuration

Container Apps health probes have specific threshold ranges:

Pattern: Use a startup probe with high failure threshold (30) for slow-starting apps instead of a high initialDelaySeconds on the liveness probe.

Container Apps Deployment

# Update with new image
az containerapp update \
  --name myapp \
  --resource-group myrg \
  --image myregistry.azurecr.io/myapp:v1.2.3

# Scale configuration
az containerapp update \
  --name myapp \
  --resource-group myrg \
  --min-replicas 1 \
  --max-replicas 10

Azure App Service

11-Step Deployment Pipeline

Typical App Service deployment takes ~7 minutes:

Rule: Always use staging slots for zero-downtime deployment. Direct-to-production deployments cause cold-start downtime.

Production Readiness Checklist

Security Posture Assessment

Pass/Fail Matrix

Use a matrix to track security controls across all resources:

Rule: Any ❌ in the matrix is a tracked remediation item with a priority (P0-P3) and SLA.

Rate Limiting

Spread vs. Burst

For API calls and deployment operations:

Rule: Prefer spread over burst for production workloads. Azure APIs throttle based on request rate, and burst patterns hit throttle limits earlier than spread patterns with the same total throughput.

Retry Pattern

async function withRetry<T>(
  fn: () => Promise<T>,
  maxRetries = 3,
  baseDelay = 1000
): Promise<T> {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    try {
      return await fn();
    } catch (err: any) {
      if (attempt === maxRetries) throw err;
      if (err.statusCode === 429) {
        // Use Retry-After header if available
        const delay = err.headers?.['retry-after']
          ? parseInt(err.headers['retry-after']) * 1000
          : baseDelay * Math.pow(2, attempt);
        await new Promise(r => setTimeout(r, delay));
      } else {
        throw err; // Don't retry non-throttle errors
      }
    }
  }
  throw new Error('Unreachable');
}

Multi-Subscription Management

Folder Organization

For organizations with multiple Azure subscriptions:

azure/
├── production/
│   ├── main.bicep
│   └── parameters.prod.json
├── staging/
│   ├── main.bicep
│   └── parameters.staging.json
├── development/
│   └── parameters.dev.json
└── shared/
    ├── modules/          # Shared Bicep modules
    └── policies/         # Azure Policy definitions

Resource Inventory

Before any infrastructure changes, document what exists:

# List all resources in subscription
az resource list --subscription "My Subscription" \
  --output table \
  --query "[].{Name:name, Type:type, RG:resourceGroup, Location:location}"

# Export to JSON for diff tracking
az resource list --subscription "My Subscription" -o json > inventory.json

Subscription Documentation Template

Each subscription should have a living document with:

Known Gotchas

Mail.Send on Corporate Tenants

Microsoft 365 corporate tenants often block Mail.Send permission for third-party apps. If your app needs to send email:

1. Check tenant admin consent policies first
2. Consider SendMail via Graph with delegated (not application) permissions
3. Have a fallback (SMTP, SendGrid) for blocked tenants
4. Document the limitation clearly for users

Azure CLI Context

# Always verify which subscription is active
az account show --query "{Name:name, Id:id}" -o table

# Set explicitly before operations
az account set --subscription "Target Subscription"

Rule: Never assume the correct subscription is active. Always verify or set explicitly in scripts.

Infrastructure as Code

Bicep Best Practices for Deployment

# Always preview changes before deploying
az deployment group what-if \
  --resource-group myrg \
  --template-file main.bicep \
  --parameters @parameters.prod.json