azure-deploy

Files (1)

• SKILL.md

SKILL.md (first lines)

# Azure Deploy

Deploy workloads to Azure with a clear, low-risk process aligned with the Well-Architected Framework.
Emphasis on idempotency, repeatable IaC, comprehensive validation, and reversible rollback paths.

## Use This Skill When

- The user asks to deploy an app or service to Azure
- The user needs release automation, blue-green, or canary deployments
- The user wants Infrastructure-as-Code guidance (Bicep, Terraform)
- The user needs rollback and disaster recovery procedures
- Deployment fails and needs troubleshooting with validation steps

## Context: Deployment Maturity Model

**Stage 1: Manual** → Portal-only, error-prone, hard to audit  
**Stage 2: Semi-Automated** → Scripts with some IaC, inconsistent across environments  
**Stage 3: Fully Automated** → Declarative IaC, CI/CD, infrastructure versioned  ← **Target**  
**Stage 4: GitOps** → All changes through pull requests, fully auditable, drift detection

## Required Inputs

- **Target environment**: subscription ID, resource group, region, tenant
- **Environment stage**: dev, test, stage, prod (with distinct names)
- **Workload type**: web app, function, container app, AKS, VM, hybrid
- **Deployment method**: Azure CLI, Bicep, Terraform, ARM template, Azure Developer CLI
- **Artifact readiness**: built container image, versioned application package
- **Security context**: managed identity vs. connection string, private endpoints, secret rotation
- **Validation criteria**: health checks, endpoint tests, smoke tests, performance baselines
- **Rollback tolerance**: how many minutes can service be unavailable?

## Decision Tree

```
Is this infrastructure or application code?
├─ Infrastructure → Use Bicep or Terraform (IaC)
└─ Application → Use Azure DevOps or GitHub Actions pipeline

Is this a net-new deployment or an update?
├─ Net-new → Deploy with full validation suite
└─ Update → Blue-green or canary strategy to minimize blast radius

Do you need instant rollback capability?
├─ Yes → Blue-green deployment (dual environments, instant traffic switch)
└─ Acceptable lag → Canary (gradual rollout with monitoring)
```

## Workflow

### Phase 1: Pre-Deployment Validation (Shift-left)

1. **Verify prerequisites**:
   - Subscription access confirmed (check quota, resource limits, API provider registration)
   - Role assignments correct for service principals or managed identities
   - Naming conventions followed (avoid reserved names, region abbreviations)
   - All secrets exist in Key Vault or secure store (never hardcode)

2. **Review IaC and artifacts**:
   - Bicep/Terraform syntax validated with `bicep build` or `terraform plan`
   - No hardcoded values (use parameters and variables)
   - Dependencies explicitly declared (`dependsOn`, references)
   - Tags and metadata complete (owner, environment, cost center)

3. **Validate security posture**:
   - Network isolation: private endpoints, NSGs, firewalls
   - Identity: managed identity or service principal with least privilege
   - Data: encryption at rest and in transit
   - Secrets stored in Key Vault with access policy

### Phase 2: Artifact Preparation

1. **Build application**:
   - Compile, test, and package application code
   - Increment version number (semantic versioning)
   - Tag artifacts with build ID or commit hash for traceability

2. **Build container (if containerized)**:
   - Push to Azure Container Registry (ACR) with multi-tag (`:latest`, `:v1.2.3`, `:sha-abcd1234`)
   - Scan image for vulnerabilities using Defender for container registries
   - Verify image can be pulled from target deployment context

3. **Archive IaC**:
   - Version Bicep or Terraform files in source control
   - Pin module versions (never use `latest`)
   - Generate parameter files for each environment (dev.bicepparam, prod.bicepparam)

### Phase 3: Deployment Execution

**Option A: Declarative (Recommended)**
```bash
az deployment group create \
  --resource-group $RG \
  --template-file main.bicep \
  --parameters main.bicepparam \
  --mode Incremental
```

**Option B: Terraform**
```bash
terraform init -backend-config=backend.tfvars
terraform plan -var-file=prod.tfvars -out=tfplan
terraform apply tfplan
```

4. **Monitor deployment progress**:
   - Watch Azure portal Activity Log or CLI output for errors
   - Check resource creation order (dependencies respected)
   - Verify DNS, network routes, and storage connectivity as resources come online

### Phase 4: Post-Deployment Validation

1. **Smoke test**:
   - Application endpoint responds (HTTP 200, health check passes)
   - Database or data store is accessible
   - Logging and monitoring are active

2. **Integration test**:
   - Dependent services (API gateways, queues, caches) are reachable
   - Data flows through expected paths

From manu14357/zskills, MIT.

More from manu14357/zskills