Deploying Containers, Binaries and Scripts in Azure

Configure and Secure Artifact-Based Deployments

CI/CD with Azure Pipelines

When deploying applications in Azure, the deployment process starts with Azure Pipelines, which automates how code moves from a developer's computer to production. Azure Pipelines supports two ways to define deployment workflows: YAML pipelines that live alongside your code in version control, and classic pipelines that use a visual designer. Both approaches can automatically build your application, run tests to verify it works, and then deploy it to Azure. Pipelines can also enforce approvals, which require a person to manually sign off before deployment proceeds, and rollback policies that automatically undo a deployment if problems are detected. Security scanning integrated into the pipeline checks your code and artifacts for vulnerabilities before they reach production.

Artifact Management with Azure Artifacts

Once your code is built, the output—called an artifact—needs to be stored somewhere that your deployment pipelines can access. Azure Artifacts provides package feeds where you can store and share container images, binary files, and deployment scripts. These feeds can be public, allowing anyone to download, or private, restricting access to only approved teams. Access controls determine who can upload new versions and who can download them for deployment. By managing artifacts in Azure Artifacts, you ensure that every deployment uses a known, tested version of your application rather than assembling pieces from unclear sources.

Deployment Strategies

The way you switch from the old version of your application to the new version matters for user experience. A blue-green deployment runs two identical environments: one serves live traffic while the other receives the update. Once the new version passes testing, traffic is switched to point to the updated environment, making the switch instant. A canary release takes a different approach by deploying the new version to a small group of users first while most users continue on the old version. If problems appear, you roll back only the canary group; if everything works, you gradually expand the new version to everyone. Both strategies reduce risk compared to replacing everything at once.

Infrastructure as Code

Rather than manually creating Azure resources through the portal, teams define their infrastructure in templates that pipelines can apply automatically. ARM templates describe resources like virtual machines, storage accounts, and networking components in a JSON format that Azure reads to create exactly what you specified. Bicep offers the same capability with a simpler, more readable syntax that compiles down to ARM templates. Using Infrastructure as Code means your environment can be recreated from scratch if needed, and changes go through the same review process as your application code.

Local Development Tools

Before deploying to Azure, developers can test their work locally using tools like Visual Studio Code with Azure extensions. These extensions let you run and debug workflows on your own machine without consuming Azure credits or waiting for cloud resources. Azure Arc extends this further by connecting on-premises servers and Kubernetes clusters to Azure, allowing you to manage them using the same tools and policies you use for cloud resources. This hybrid approach lets organizations gradually move to the cloud while keeping some workloads running in their own data centers.