Azure DevOps and Pipelines

Azure DevOps is Microsoft's integrated suite for planning work, hosting Git repositories, running CI/CD pipelines, managing packages, and tracking tests. Azure Pipelines is the automation service inside that suite that builds, tests, and deploys your code on Microsoft-hosted or self-hosted agents.

itDevOps and software delivery

Don't Panic: Azure DevOps and Pipelines

Azure DevOps is Microsoft's "we already work here" suite: Boards for the backlog, Repos for the Git bits, Pipelines for the robots that build and ship, Artifacts for the packages those robots publish, and Test Plans when a human still has to click through a checklist. One project keeps the paperwork attached to the commits attached to the runs, which is the whole point of buying a suite instead of five stickers.

Azure Pipelines is the part that actually does the midnight work. Picture nested boxes. The outer box is the pipeline. Inside it are stages (Build, then Deploy, if you are feeling orderly). Inside a stage are jobs, and each job claims one agent. Inside a job are steps: tasks and scripts that share a workspace until the job ends.

Microsoft would like your new pipelines to be YAML in the repo, usually azure-pipelines.yml, so pipeline edits face the same review as application edits. Classic pipelines still haunt the portal for older definitions. They are not evil; they are not where new features go to live.

Agents come in personalities. Microsoft-hosted agents hand you a fresh VM and then discard it, which is wonderfully unsentimental. Self-hosted agents live on your network with your tools and your grudges. Pools are how a job asks for the right personality. If a run sits in queue forever, you are usually out of parallel jobs or out of matching agents, not out of hope.

Two surprises separate people who skim marketing from people who ship:

First, variables care when they expand. Template expressions fire early; runtime values arrive late; secrets are masked in logs and still readable to a job that wants them. Second, Environments, service connections, and approvals are how Production actually says no. Those checks live on the resource in the portal. They are not a comment you can delete in YAML and call a refactor.

Templates are how organizations stop reinventing npm ci. Include templates reuse steps. Extends templates politely insist that your pipeline look like the approved shape, scans included.

If you only open one more tab, use Don't Panic's siblings like this: the intro for the suite map, the cheatsheet when you forget whether environment belongs on a deployment job, Field Notes when someone asks who may edit the prod pipeline, and the practice reference when you want a command that already survived contact with reality.

Don't Panic: Azure DevOps and Pipelines

Relevant careers