Deployment Methods¶
Azure App Service supports multiple deployment paths, but they are not interchangeable. The right choice depends on whether you are deploying prebuilt artifacts, source-controlled application code, staged releases, or custom container images.
Main Content¶
Deployment Method Comparison¶
| Method | Use Case | Pros | Cons |
|---|---|---|---|
| ZIP Deploy | Deploy a prebuilt artifact directly from a local package or remote package URL | Simple CLI workflow, deterministic artifact delivery, works well with WEBSITE_RUN_FROM_PACKAGE | No built-in approval flow, weaker release governance than full CI/CD |
| GitHub Actions | Build, test, and deploy from a GitHub repository | Native CI/CD, quality gates, reusable workflows, good fit for team automation | Requires identity and secret management, more moving parts than direct deploy |
| Slots and Swap | Release to staging, validate, then promote with near zero downtime | Safer promotion path, fast rollback, blue-green and canary patterns | Requires Standard tier or higher and careful slot setting hygiene |
| Container Deploy | Run a custom Linux container image from Azure Container Registry | Runtime consistency, container portability, image-based promotion | More operational complexity, image lifecycle and registry access must be managed |
Deployment Decision Flow¶
flowchart TD
A[Need to deploy to Azure App Service] --> B{Running a custom container image?}
B -- Yes --> C[Use Container Deploy]
B -- No --> D{Need automated CI/CD from GitHub?}
D -- Yes --> E[Use GitHub Actions]
D -- No --> F{Deploying a prebuilt package?}
F -- Yes --> G[Use ZIP Deploy]
F -- No --> H[Use source-based workflow or language guide pipeline]
C --> I{Need low-risk promotion?}
E --> I
G --> I
I -- Yes --> J[Add deployment slots and swap]
I -- No --> K[Deploy directly to production] How to Choose¶
- Start with the artifact format: ZIP package, repository workflow, or container image.
- Decide whether release promotion needs staging validation before production exposure.
- Prefer immutable artifacts or immutable images for production deployments.
- Externalize mutable state such as uploaded files, sessions, and secrets.
Common production baseline
A common production pattern is GitHub Actions for build/test, staging slot for validation, and slot swap for promotion. Use ZIP Deploy when you already have a prebuilt artifact and want a simpler delivery path.
Detailed Guides¶
| Guide | Focus |
|---|---|
| ZIP Deploy | az webapp deploy --type zip, artifact packaging, and WEBSITE_RUN_FROM_PACKAGE |
| GitHub Actions | GitHub workflow templates, Azure authentication, slot deployment, and promotion |
| Slots and Swap | Slot creation, sticky settings, manual swap, auto-swap, and blue-green rollout |
| Container Deploy | Azure Container Registry integration, custom container creation, and webhook-based CD |
Recommended Pairings¶
| Delivery Mechanism | Promotion Mechanism | Typical Fit |
|---|---|---|
| ZIP Deploy | Direct production deployment | Small teams, emergency fix, prebuilt artifact push |
| ZIP Deploy | Staging slot + swap | Controlled artifact release with rollback |
| GitHub Actions | Direct production deployment | Lower-risk internal apps with full CI coverage |
| GitHub Actions | Staging slot + swap | Team-based production release workflow |
| Container Deploy | Staging slot + swap | Platform teams standardizing on container images |
Existing slot operations guide
For broader operational guidance on slot lifecycle, validation, rollback, and canary routing, also see Deployment Slots Operations. This deployment section focuses on deployment-method selection and execution patterns rather than duplicating that page.
Advanced Topics¶
- Prefer build once, deploy many so every environment receives the same artifact or image.
- Use slot-specific settings for environment-dependent values such as connection strings or downstream endpoints.
- For high-change environments, standardize on one primary release path to reduce operational drift.