Deploying Containers, Binaries, Scripts and Databases

What it is

After the strategy is chosen, something has to put the application on the target. This topic covers the three common forms: containers (an image pushed to a registry and run on a platform), binaries (a package or zip deployed to a host) and scripts (Azure CLI, PowerShell or Bash that do the work), plus the special case of deploying database changes.

How it works

Containers

1. Build the image and push it to a registry such as Azure Container Registry (ACR).
2. Tag it with something unique, such as the build ID or commit SHA.
3. Scan the image for vulnerabilities before deploying.
4. Deploy to a runtime that pulls the image by tag or digest.

Build and push with Docker@2 (the buildAndPush command), or let ACR build the image in the cloud (az acr build), which avoids needing Docker on the agent. Let the target pull with a managed identity that has the AcrPull role, instead of a registry password. In GitHub Actions the equivalents are the docker/build-push-action, azure/k8s-deploy and azure/webapps-deploy actions.

- task: Docker@2
  inputs:
    containerRegistry: my-acr-connection
    repository: shop/web
    command: buildAndPush
    tags: |
      $(Build.BuildId)

Binaries and packages

For classic application hosting, you build once, publish the result as an artifact, and deploy that same artifact to each environment.

Publish with PublishPipelineArtifact@1 and download with the download step in later jobs and stages, so every environment receives the identical bits.

Scripts

Scripts cover anything without a dedicated task.

Good deployment scripts are idempotent, take their settings as parameters or environment variables, exit with a non zero code on failure (so the step fails) and never print secrets.

Database deployments

Application code can be replaced. Data cannot. Database changes need extra care.

Safe practices:

• Use expand and contract: first add the new column or table in a change that works with the old and the new code, deploy the code, then remove the old structure in a later release. This makes rollback possible.
• Run schema changes as a separate stage with an approval, before the application stage, and test them on a copy of production data first.
• Give the pipeline identity least privilege and prefer Microsoft Entra authentication to SQL passwords.
• Back up or snapshot before destructive changes, and prefer roll forward because data written by the new version may not fit the old schema.

A worked scenario

A team ships a web API as a container and a SQL database. The pipeline builds the image once with Docker@2, tags it with $(Build.BuildId), scans it, and pushes it to ACR. A migration stage runs an idempotent EF Core script against staging, then production after approval. A deploy stage updates the AKS manifest with the new tag, using a canary step. The column rename the developers wanted is split into add column, then move data, then drop column in a later release.