Deployment Best Practices¶

This guide describes safe deployment patterns for Azure Functions by hosting plan, trigger model, and rollback requirements. It focuses on immutable artifacts, release validation, and operational guardrails that prevent runtime regressions.

Why This Matters¶

Choose the deployment method that matches plan capabilities. Incorrect method selection is a common cause of failed releases.

Recommended Practices¶

Why run-from-package should be default¶

Run-from-package mounts a built artifact as a read-only package. This removes in-place mutation risk and keeps all instances on the same bits.

Operational benefits¶

• Prevents partial file copy states during rollout.
• Keeps deployed code immutable across scale-out events.
• Simplifies rollback to a known artifact version.
• Reduces "works on one instance only" drift.

az functionapp config appsettings set \
    --resource-group "<resource-group>" \
    --name "<app-name>" \
    --settings WEBSITE_RUN_FROM_PACKAGE=1

Slot strategy by plan¶

Slot usage must match plan limits and trigger behavior.

Consumption (Y1)¶

• Maximum of two slots total (production + one non-production).
• Use a single staging slot for smoke test then swap.
• Keep storage and secret source settings slot-sticky when values differ by environment.

Flex Consumption (FC1)¶

• No slots; use artifact promotion and config rollback patterns.
• Validate release in an isolated FC1 app before production publish.

Premium and Dedicated¶

• Use at least staging and optionally preprod slots.
• Warm slot before swap and run trigger-aware smoke tests.
• Use swap-back as first rollback path.

Slot-sticky settings (minimum set)¶

Mark these as slot settings when values differ between staging and production:

• AZURE_FUNCTIONS_ENVIRONMENT
• Connection strings and endpoint URIs
• Key Vault reference targets
• Feature flags controlling trigger enablement
• Any test-only dependency endpoints

az functionapp config appsettings set \
    --resource-group "<resource-group>" \
    --name "<app-name>" \
    --slot "staging" \
    --slot-settings AZURE_FUNCTIONS_ENVIRONMENT=Staging

CI/CD pipeline design for Functions¶

Use repository-driven pipelines (GitHub Actions or Azure DevOps) with identity-based auth and immutable artifacts.

Core design rules¶

1. Build once, deploy many (same artifact per environment).
2. Use OpenID Connect (OIDC) federation for Azure auth.
3. Cache dependencies for deterministic and faster builds.
4. Block production deploy until smoke checks pass.

GitHub Actions vs Azure DevOps¶

Deployment validation and release safety¶

Validation must prove runtime readiness, not just deployment success.

Required validation stages¶

1. Health probe: host is started and bindings initialized.
2. Smoke tests: call at least one HTTP path and one trigger path (queue/event) where applicable.
3. Telemetry guard: check exceptions, cold start spikes, and queue age after release.
4. Gate decision: swap/publish only if checks pass.

Health endpoint pattern¶

• Expose a lightweight endpoint that verifies host readiness and critical dependency reachability.
• Do not include PII in health payloads.
• Keep timeout low to avoid masked dependency slowness.

Rollback patterns¶

Choose rollback path based on plan capabilities.

Recommended rollback order¶

1. Slot swap-back (if slots exist).
2. Redeploy last-known-good package.
3. Reapply last-known-good configuration snapshot.

flowchart LR
    A[Deploy artifact to staging slot or isolated preprod app] --> B[Run health and trigger-aware smoke tests]
    B --> C{Validation passed}
    C -->|Yes| D[Swap to production or promote artifact]
    D --> E[Monitor telemetry guard window]
    E --> F{Regression detected}
    F -->|No| G[Keep release and close deployment]
    F -->|Yes| H[Execute rollback path]
    C -->|No| H
    H --> I{Slots available}
    I -->|Yes| J[Swap-back immediately]
    I -->|No| K[Redeploy last-known-good artifact]
    K --> L{Issue due to configuration drift}
    L -->|Yes| M[Apply last-known-good config snapshot]
    L -->|No| N[Continue incident troubleshooting]
    J --> O[Post-rollback validation]
    M --> O

flowchart TD
    A[Production issue after deployment] --> B{Is slot swap-back available and low risk?}
    B -->|Yes| C[Swap-back first]
    B -->|No| D{Is prior artifact validated and available?}
    D -->|Yes| E[Redeploy prior artifact]
    D -->|No| F[Apply configuration rollback snapshot]
    C --> G[Validate recovery metrics]
    E --> G
    F --> G
    G --> H{Service stable?}
    H -->|Yes| I[Close rollback action]
    H -->|No| J[Escalate incident and deep-dive diagnostics]

Common Mistakes / Anti-Patterns¶

Validation Checklist¶

Pre-deploy¶

• Confirm plan-specific deployment method compatibility.
• Confirm artifact built once and signed/versioned.
• Confirm WEBSITE_RUN_FROM_PACKAGE strategy for supported plans.
• Confirm slot-sticky settings list is current.
• Confirm rollback artifact/config snapshot exists.

During deploy¶

• Deploy to staging slot (or isolated pre-production app on FC1).
• Run health and trigger-aware smoke tests.
• Review telemetry deltas (exceptions, queue age, latency percentiles).
• Approve cutover only after gates pass.

Post-deploy¶

• Re-check trigger lag/backlog and failure rate.
• Verify budget and scale guardrails remain intact.
• Capture release metadata for incident correlation.

flowchart TD
    A[Commit and Build] --> B{Hosting plan}
    B -->|Y1| C[ZIP deploy to staging slot + run-from-package]
    B -->|FC1| D[func publish or One Deploy]
    B -->|EP or Dedicated| E[ZIP deploy to staging slot + warm + test]
    C --> F[Health and smoke validation]
    D --> F
    E --> F
    F --> G{Validation passed}
    G -->|Yes| H[Swap or promote artifact]
    G -->|No| I[Rollback artifact or config]
    H --> J[Post-deploy telemetry gate]

See Also¶

• Operations: Deployment
• Platform: Hosting
• Platform: Scaling
• Troubleshooting Playbooks

Sources¶

• Deployment technologies in Azure Functions (Microsoft Learn)
• Run Azure Functions from a deployment package (Microsoft Learn)