deployment
What it is
An application deployment releases a chosen, versioned application artifact into a target environment so it can run there. It is more than copying files: a controlled deployment identifies what version is changing, checks it, applies it to the intended environment, observes the result, and provides a recovery path.
Think of replacing a restaurant’s menu during service. The team prepares and reviews the new menu, puts it on a small number of tables first, watches for problems, then expands it—or restores the previous menu if it confuses customers.
Why it exists
Manual releases often differ between test and production and leave little evidence of what changed. A repeatable delivery process makes releases more predictable, reviewable, and easier to investigate or reverse.
Key ideas
- An artifact is the versioned thing to deploy: for example, a compiled application package, container image, or a set of infrastructure definitions.
- Continuous integration (CI) builds and tests changes. Continuous delivery (CD) promotes tested artifacts through one or more environments. CI creates confidence in an artifact; CD controls where that artifact goes.
- An environment is a target boundary such as development, test, staging, or production. Keep its configuration and permissions explicit rather than assuming a test deployment is identical to production.
- A deployment pipeline can use tests, security checks, approvals, and gates before promotion. Automation makes the process repeatable; it does not make an unsafe change safe without meaningful checks.
- Progressive techniques such as canary releases, rings, blue/green routing, and feature flags limit the number of affected users while the team observes a new version.
Northwind example
Luis’s pipeline builds and tests version 2026.09.16.3 of Northwind’s ordering application, then publishes one immutable artifact. The pipeline deploys that exact artifact to staging, runs smoke tests, and requires approval before production. In production, it first sends a small share of traffic to the new version and watches Azure Monitor for checkout failures. If failures increase, the team routes traffic back to the known-good version or rolls forward with a corrected build. They record the version, configuration reference, approver, and observed result.
Application deployment versus infrastructure deployment
| Activity | What changes |
|---|---|
| Application deployment | The code or image that runs the workload. |
| [[bicep | Infrastructure as code]] deployment |
| [[azure-app-configuration | Configuration change]] |
One release can coordinate all three, but they have different risks, permissions, validation, and rollback plans.
Common confusion
- A successful pipeline task proves only that task’s configured operation succeeded. Confirm the user-visible behavior and monitor after release.
- A rollback is not always automatic or safe, especially after database schema or data changes. Plan compatibility and recovery before deployment.
- Deploying frequently is valuable only when artifacts are traceable and checks, observability, and ownership make failures manageable.
Related
delivery-pipeline · bicep · arm-template · app-service · deployment-slots · azure-app-configuration · azure-monitor · northwind-traders-case-study
Sources and re-audit
- Microsoft Learn — What is continuous delivery?, checked 2026-09-16.
- Microsoft Learn — Key Azure Pipelines concepts, checked 2026-09-16.