Investigate app service deployment slot

[puicchan]

[vhvb1989]

Feature in Aspire 13.1 -> https://aspire.dev/whats-new/aspire-13-1/#azure-app-service-deployment-slots

[vhvb1989]

related doc: dotnet/docs-aspire#5958

[vhvb1989]

Azure provides two major approaches for zero‑downtime deployments:

• Azure Web Apps (App Service) with Deployment Slots
• Azure Container Apps using Blue/Green (revision‑based) deployments

Both allow you to deploy a new version alongside the current one, validate it, and then switch traffic — but the underlying mechanisms differ significantly.

---

🧩 2. Architecture & Requirements

Feature / Requirement	Azure Web App (Deployment Slots)	Azure Container Apps (Blue/Green)
Compute model	App Service Plan	Container Apps Environment (Kubernetes‑based)
Deployment unit	Code or container	Container image only
Blue/Green mechanism	Separate slots (staging, production)	Revisions with labels (blue/green)
Traffic switching	Slot swap (atomic)	Traffic weights + revision labels
Rollback	Swap back instantly	Reassign traffic to previous revision
Isolation	Slots share same plan	Revisions run as separate instances
Networking	App Service networking	VNET, Dapr, scale rules
Scaling	App Service autoscale	KEDA autoscaling
Cost model	Slots included in plan	Each active revision consumes compute
Best for	Traditional web apps	Container‑native workloads, microservices

---

🔄 3. Deployment Flow Comparison

Azure Web App Deployment Slots

Typical Flow

1. Create a staging slot
2. Deploy new version to staging
3. Warm up & test using staging URL
4. Swap staging ↔ production
5. Roll back by swapping again if needed

Characteristics

• Swap is atomic and platform‑managed
• Very simple workflow
• Ideal for teams not using container‑native patterns

---

Azure Container Apps Blue/Green (Revisions)

Typical Flow

1. Enable multiple active revisions
2. Deploy new revision (green)
3. Test using revision‑specific FQDN
4. Shift traffic gradually (0% → 10% → 100%)
5. Promote green revision
6. Roll back by shifting traffic back to previous revision

Characteristics

• Native support for canary and gradual rollout
• Very flexible traffic routing
• Ideal for microservices and event‑driven architectures

---

🧪 4. Testing & Validation Differences

Aspect	Web App Slots	Container Apps Blue/Green
Testing URL	Each slot has its own URL	Each revision has its own FQDN
Environment parity	Slots share same plan	Revisions are fully isolated
Canary support	Not built‑in	Native traffic weighting

---

🧯 5. Rollback Behavior

Web Apps

• Rollback = swap back
• Very fast
• Tied to slot configuration

Container Apps

• Rollback = reassign traffic to previous revision
• No swap required
• Both revisions can remain active

---