Fast Deployment Path

The fast deployment path (fast-deploy-pipeline.yml) is a streamlined pipeline that skips infrastructure provisioning. It rebuilds and redeploys one or more container images in 3–8 minutes compared to the 20–30 minutes of a full deploy.

When to Use Fast Deploy

Decision Checklist

Before using fast deploy, confirm ALL of these are true:

[ ] Only application source code changed (.cs, .csproj, .razor)
[ ] No new environment variables added or existing ones modified
[ ] No changes to services-config.json
[ ] No Bicep or infrastructure YAML changes
[ ] No new services being introduced
[ ] Target service is already deployed and healthy
[ ] No database migration scripts in this change

If any box is unchecked, use the full deployment pipeline (e.g., platforms-pipeline.yml) instead.

Fast Deploy Steps

Pipeline Parameters

The fast deploy pipeline (pipelines/container-backend/fast-deploy-pipeline.yml) uses serviceToggles — the same boolean-per-service pattern as the full deploy pipelines. Select which services to deploy by enabling their toggle:

yaml

# Triggered manually via Azure DevOps UI or az CLI
parameters:
  - name: targetEnvironment
    displayName: Target Environment
    type: string
    default: dev
    values:
      - dev
      - stage
      - preprod
      - uat

  - name: deployMode
    displayName: Deployment Mode
    type: string
    default: manual
    values:
      - manual
      - force-all

  - name: skipApproval
    displayName: Skip Approval Gate
    type: boolean
    default: false

  # Service toggles (one per service)
  - name: svc_appsportalApi
    displayName: '[Platforms] AppsPortal API'
    type: boolean
    default: false

  - name: svc_inventoryApi
    displayName: '[Platforms] Inventory API'
    type: boolean
    default: false

  # ... (all 13 service toggles follow this pattern)

No serviceName or imageTag Parameters

The fast deploy pipeline does not accept a single serviceName string or an imageTag string. Services are selected via boolean toggles. The image tag is always derived from $(Build.BuildId).

Trigger via Azure DevOps UI

Navigate to Pipelines → fast-deploy-pipeline
Click Run pipeline
Select targetEnvironment
Enable the toggle for the service(s) to deploy
Click Run

Time Comparison

Deploy Type	Pipeline	Estimated Time	Skips
Full deploy	`platforms-pipeline.yml` (and others)	20–30 min	Nothing
Fast deploy	`fast-deploy-pipeline.yml`	3–8 min	Bicep, smoke suite
Frontend only	`front-apps/` pipelines	15–25 min	Backend services

What Fast Deploy Does NOT Do

Fast Deploy Limitations

These tasks are explicitly skipped in fast deploy. If your change requires any of them, use the full deploy instead.

Skipped Step	Impact if Needed
Bicep infrastructure deployment	New resources won't be created; scaling changes won't apply
`services-config.json` parsing	New env vars, replica counts, CPU/memory won't update
Azure Front Door reconfiguration	New routes or custom domains won't activate
Full smoke test suite	Only readiness probe checked; integration tests skipped
Database migration	Schema changes won't be applied (always use full deploy for migrations)
Multi-service coordination	Only one service deployed; no cross-service compatibility check

Rollback

If a fast-deployed revision causes issues, roll back to the previous revision:

bash

# List recent revisions
az containerapp revision list \
  --name accounting \
  --resource-group mic-erp-be-stage-apps-rg \
  --output table

# Activate a previous revision
az containerapp ingress traffic set \
  --name accounting \
  --resource-group mic-erp-be-stage-apps-rg \
  --revision-weight previous-revision-name=100

# Deactivate the bad revision
az containerapp revision deactivate \
  --name accounting \
  --resource-group mic-erp-be-stage-apps-rg \
  --revision bad-revision-name

Azure Container Apps retains the last 10 revisions per container app, enabling instant rollback.

Fast Deploy on Production

Production Fast Deploy Requires Approval

Even though fast deploy skips many steps, deploying to production still requires a manual approval gate. Production deployments must use production-release-pipeline.yml, not the fast deploy pipeline — fast-deploy-pipeline.yml only accepts dev, stage, preprod, and uat as environment values.

Do NOT use fast deploy to bypass the production change management process. The approval gate is enforced at the pipeline level via Azure DevOps environment protection rules.

Production-specific safeguards in fast deploy:

Manual approval gate (any 1 of: Release Manager, CTO)
15-minute extended health check after revision activation
Automatic rollback if readiness probe fails within 5 minutes

Monitoring After Fast Deploy

After a fast deploy, monitor these dashboards for 10–15 minutes:

Dashboard	What to Watch
Application Insights → Live Metrics	Request failure rate, exceptions
Container Apps → Revision logs	Pod startup errors, unhandled exceptions
Azure Monitor → Alerts	Any triggered metric alerts

bash

# Stream container logs immediately after fast deploy
az containerapp logs show \
  --name accounting \
  --resource-group mic-erp-be-stage-apps-rg \
  --follow \
  --tail 50

Orchestrators — Full description of all 6 pipelines
CI/CD Overview — When to use full deploy vs fast deploy
Services Config — How service names map to source paths
Branch/Env Mapping — Environment configuration

Fast Deployment Path ​

When to Use Fast Deploy ​

Decision Checklist ​

Fast Deploy Steps ​

Pipeline Parameters ​

Trigger via Azure DevOps UI ​

Time Comparison ​

What Fast Deploy Does NOT Do ​

Rollback ​

Fast Deploy on Production ​

Monitoring After Fast Deploy ​

Related Documentation ​