Lesson225 words
Deploying containers, binaries and scripts
Implement application deployment by using containers, binaries, and scripts
Build once, deploy many
The artifact produced by the build stage is what every environment receives. Rebuilding per environment breaks the guarantee that what you tested is what you shipped.
yaml
- publish: $(Build.ArtifactStagingDirectory)
artifact: drop
# ...later, in the deploy stage
- download: current
artifact: dropEnvironment differences belong in configuration — variable groups, slot settings, App Configuration — not in separate builds.
The three shapes
| Shape | Immutability | Notes |
|---|---|---|
| Container image | Highest — image digest pins the whole userland | Promote the same digest through environments; a re-pushed :latest tag breaks the guarantee |
| Binary / package | Good — versioned artifact | Feeds, retention and versioning via Azure Artifacts or GitHub Packages |
| Script | Lowest — behaviour depends on the target machine | Must be idempotent; pin tool versions |
Containers
Tag by immutable identity, not by latest. latest is a moving pointer, so "the image we tested" and "the image we deployed" can silently differ. Promote by digest or an immutable version tag.
Scripts
A script's result depends on the state of the machine it lands on — exactly the self-hosted-agent contamination problem. Idempotency and pinned tool versions are the mitigations.
Primary sources