Set Up Azure DevOps Pipelines

You've built the app, containerized it, and pushed it to a registry — but every time you deploy manually, something breaks. The pain is real: a forgotten environment variable, a wrong image tag, a build that works on your machine but fails in production. That's the gap Azure DevOps Pipelines fills: an automated, repeatable, and auditable path from code commit to cloud deploy. In this lesson, you'll learn how to set up Azure DevOps pipelines from scratch — define a YAML-based continuous integration (CI) and continuous delivery (CD) workflow, run it on Microsoft-hosted agents, and connect it to your Azure resources — so you can ship with confidence and stop babysitting deployments.

The Problem This Lesson Solves

Manual deployment is a ticking time bomb. When you deploy by hand, you accept several risks:

• Human error: You forget to run migrations or set APP_ENV=production.
• Inconsistency: The build you tested locally isn't the artifact you deploy.
• No audit trail: If something breaks, you can't answer "what changed?"
• Slow feedback: Bugs surface hours after commit, not minutes.

Azure DevOps Pipelines solves these by encoding your entire release process into a checked-in file — azure-pipelines.yml. Every push to your branch triggers a build, runs tests, packages the artifact, and deploys to Azure — automatically, every time, the same way.

The pain is especially acute in a team: without a pipeline, "it works on my machine" becomes a recurring nightmare. You need a single source of truth for how your app is built, tested, and shipped. That's precisely what this lesson gives you.

Core Concept / Mental Model

Think of Azure DevOps Pipelines as a conveyor belt in a factory. Raw materials (your code) enter on one end, and finished goods (deployed app) exit on the other. The belt is your pipeline, and each station is a stage. Within a stage, you have jobs (work units), and each job runs a series of steps (tasks) in order.

Here’s the vocabulary you need:

• Pipeline: The entire YAML definition.
• Trigger: What starts the pipeline — typically a branch push or a PR.
• Agent: The machine where steps run. Azure DevOps provides Microsoft-hosted agents (pre-configured with common tools) or you can use self-hosted agents (your own VMs).
• Stage: A major phase — e.g., Build, Test, Deploy.
• Job: A set of steps that run on the same agent.
• Step: A single action — run a script, publish an artifact, deploy to Azure.
• Artifact: The packaged output of your build that gets handed to the release stage.

A simple mental model: Trigger → Agent → Stages → Jobs → Steps → Artifacts → Deploy. When you commit code, the pipeline picks up the change, runs your build and tests, produces a deployable artifact, and pushes it to your environment.

How It Works Step by Step

Setting up Azure DevOps Pipelines follows a predictable sequence. Here’s the cause-and-effect chain:

1. Create an Azure DevOps organization and project — your pipeline lives inside a project that contains repos, pipelines, and release targets. Cause: you need a logical container for your automation.
2. Connect your code repository — Azure DevOps can pull from its own azure-pipelines repo, GitHub, or Bitbucket. Cause: the pipeline needs a source of code to build.
3. Define your pipeline with azure-pipelines.yml — this file declares triggers, agents, stages, and tasks. Cause: the pipeline is code, versioned alongside your app.
4. Run the pipeline — Azure DevOps spins up an agent, runs your steps, and shows logs in real time. Cause: execution is observables, so you can debug issues.
5. Publish artifacts — the build stage produces a zip or a container image that the release stage consumes. Cause: artifacts make deployments reproducible.
6. Deploy to Azure — you add a deployment job that uses the Azure CLI, ARM templates, or Azure App Service task to push your artifact to a resource like an App Service or AKS. Cause: the app actually reaches your infrastructure.
7. Monitor and iterate — logs, tests, and release gates give you feedback, and you tweak the YAML for future commits. Cause: continuous improvement.

Every step depends on the previous one — if your YAML has a syntax error, the pipeline fails at step 4, not at deployment.

Hands-On Walkthrough

Now, let’s set up Azurę DevOps pipelines for a small Python web app. We’ll assume you have an Azure DevOps organization (create one for free at dev.azure.com) and have a repo with a basic app.py and requirements.txt.

1. Create Your azure-pipelines.yml

Start with a minimal CI pipeline that runs tests and publishes an artifact:

# azure-pipelines.yml
trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: |
    python -m pip install --upgrade pip
    pip install -r requirements.txt
  displayName: 'Install dependencies'

- script: |
    python -m pytest
  displayName: 'Run tests'

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.SourcesDirectory)'
    ArtifactName: 'drop'

Replace pytest with your test runner if different. Push this file to your repo’s main branch.

2. Create the Pipeline in Azure DevOps

• In your Azure DevOps project, go to Pipelines → New Pipeline.
• Choose your repository (Azure Repos, GitHub, etc.).
• Select Existing Azure Pipelines YAML file and point to azure-pipelines.yml.
• Click Run — this creates a pipeline that triggers on every push to main.

3. Add a Deployment Stage

To actually deploy, extend the YAML. Here’s a multi-stage pipeline that builds and deploys to an Azure App Service:

# azure-pipelines.yml
trigger:
- main

variables:
  azureServiceConnectionId: 'your-service-connection'  # Create this in Project Settings
  appName: 'my-python-app'

stages:
- stage: Build
  jobs:
  - job: BuildJob
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - script: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt
      displayName: 'Install dependencies'
    - script: |
        python -m pytest
      displayName: 'Run tests'
    - task: ArchiveFiles@2
      inputs:
        rootFolderOrFile: '$(Build.SourcesDirectory)'
        includeRootFolder: false
        archiveType: 'zip'
        archiveFile: '$(Build.ArtifactStagingDirectory)/$(appName).zip'
    - task: PublishBuildArtifacts@1
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'drop'

- stage: Deploy
  dependsOn: Build
  jobs:
  - deployment: DeployJob
    pool:
      vmImage: 'ubuntu-latest'
    environment: 'production'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: '$(azureServiceConnectionId)'
              appName: '$(appName)'
              package: '$(Pipeline.Workspace)/drop/*.zip'

You’ll need a Service Connection to authenticate: go to Project Settings → Service connections → New service connection → Azure Resource Manager and select your subscription.

4. Run and Observe

Commit a change to main. The pipeline will start automatically. In the Azure DevOps UI, you can watch each stage’s logs, see test results, and inspect the published artifact. When the deployment finishes, your app is live on Azure.

Pro tip: Use ci triggers for PRs. Add pr: - main to run the pipeline on pull requests — it catches issues before merging.

Compare Options / When to Choose What

When you set up Azure DevOps pipelines, you have choices for how to define and run them. Here’s a quick comparison:

For almost all modern scenarios, YAML pipelines beat classic releases because they bring the same benefits as infrastructure-as-code: versioning, reviewability, and testability. Use classic release pipelines only if you have a legacy system that’s already built on it and you don’t want to migrate.

Another comparison: Microsoft-hosted agents vs self-hosted.

• Microsoft-hosted agents: quick to start, pre-installed tools, no maintenance — but limited to available VM images.
• Self-hosted agents: full control over OS, cached dependencies, faster builds — but you manage the VM and its updates.

Choose Microsoft-hosted for simplicity; choose self-hosted if you need proprietary libraries or want to reuse a warm build cache.

Troubleshooting & Edge Cases

Here are the most common failures when you set up Azure DevOps pipelines, and how to fix them.

Error: "No hosted parallelism has been purchased or granted"

Cause: Free-tier accounts may need to request parallelism. Fix: Go to Azure DevOps portal → Organization settings → Billing → Parallel jobs → clear the request or purchase a paid plan. It’s a known stumbling block.

Error: "The service connection does not exist or has not been authorized"

Cause: You referenced a service connection name that isn’t valid. Fix: In Project Settings, confirm the exact name, and check you have permissions to use it. Use a variable for the connection ID.

Tests pass locally but fail in pipeline

Cause: Different Python version or missing environment variables. Fix: Pin your Python version in the pipeline (e.g., python: 3.11), and define variables for secrets as pipeline variables or a variable group.

Deployment says "app is up" but health check fails

Cause: Your app needs a startup command, or PORT isn’t set. For Azure App Service, set Configuration → General settings → Startup Command to python -m app or similar. For containers, define EXPOSE and PORT correctly.

Artifacts not found in deploy stage

Cause: The publish step didn’t place artifacts where you think. Fix: Use $(Build.ArtifactStagingDirectory) consistently and download in the deploy stage with DownloadBuildArtifacts@1 if needed.

What You Learned & What's Next

In this lesson, you learned how to set up Azure DevOps pipelines from scratch. You now understand the core components — triggers, agents, stages, jobs, steps, and artifacts — and you completed a hands-on exercise where you defined a YAML pipeline that runs tests, publishes artifacts, and deploys to Azure. You compared YAML vs classic releases and troubleshooted common errors like service connection issues and parallelism limits. These skills let you automate delivery for any Azure-backed app.

Your learning doesn’t stop here. The next step in this Azure track is Deploying containers to Azure Kubernetes Service (AKS) — where you’ll take the pipeline you just built and extend it to push container images and roll out releases with zero downtime. You’ll apply the same pipeline principles but with docker build and kubectl steps. You’re building toward a full DevOps chain, and pipelines are the glue.