Azure Pipelines
Azure Pipelines is the CI/CD engine within Azure DevOps: YAML-defined build-test-deploy workflows triggered by commits and pull requests, running on Microsoft-hosted or self-hosted agents, deploying to Azure or any other target. It turns a commit into a tested artifact and a governed release without manual steps.
The defining practice is pipeline-as-code: the workflow lives in YAML in the repository, versioned and reviewed alongside the application. A pipeline clicked together in a UI cannot be code-reviewed, diffed, or rolled back — defining it in YAML is what makes the delivery process itself a first-class, auditable artifact.
YAML Pipelines
A pipeline is defined in a YAML file in the repo, describing stages, jobs, and steps. Because it is in source control, a change to the build or release process goes through the same review and history as a code change. Triggers run it on commits to chosen branches and on pull requests, so validation is automatic rather than remembered.
Agents
Jobs run on agents. Microsoft-hosted agents are fresh, maintained VMs per run — zero maintenance, good for most builds. Self-hosted agents are machines you run, for builds that need specific hardware, private-network access, or large caches you do not want to rebuild each run. The choice trades convenience against control and the ability to reach private resources.
Stages, Environments, and Approvals
Pipelines model a release as stages targeting environments (dev, staging, production), with approval checks and gates between them. A required manual approval before the production stage, or an automated gate on a monitoring signal, is how a pipeline enforces a controlled promotion rather than shipping straight to production on every merge.
Deploy Anywhere
Despite the name, Pipelines deploys to any target — Azure, AWS, on-premises, Kubernetes, mobile stores — and builds on Windows, Linux, and macOS agents. It is not limited to Azure-hosted workloads, which makes it a credible CI/CD choice even for teams whose deployment targets are mixed.
Azure Pipelines — Mature CI/CD in Azure DevOps with rich release stages, environments, and approval gates. Strong for enterprise release governance.
GitHub Actions — CI/CD native to GitHub with a vast marketplace of community actions. The default when the code already lives in GitHub.
- Defining pipelines in the UI instead of YAML in the repo, so the delivery process cannot be reviewed, diffed, or rolled back.
- Using a self-hosted agent where a Microsoft-hosted one would do, taking on maintenance for no benefit.
- Using a Microsoft-hosted agent for a build that needs private-network access or specific hardware, then fighting the limitation.
- Deploying straight to production on every merge with no environment approvals or gates.
- Hard-coding secrets in the pipeline YAML instead of using a variable group backed by Key Vault.
- Assuming Pipelines only deploys to Azure and ruling it out for mixed-target environments.
- Define pipelines as YAML in the repository so the process is versioned, reviewed, and reversible.
- Use Microsoft-hosted agents by default; reserve self-hosted for private access or special hardware.
- Model releases as stages and environments with manual approvals or automated gates before production.
- Pull secrets from Key Vault via variable groups rather than embedding them in YAML.
- Run pipelines on pull requests for automatic validation before merge.
- Use Pipelines for mixed deployment targets — it deploys well beyond Azure.
Knowledge Check
Why define a pipeline as YAML in the repository rather than in the UI?
- It becomes versioned, reviewable, diffable, and reversible like any other code
- YAML pipelines run measurably faster at runtime than UI-defined ones
- Only YAML pipelines can deploy to Azure App Service, AKS, and other first-party Azure targets
- UI-defined pipelines cannot run on the Microsoft-hosted agent pool
When is a self-hosted agent the right choice over a Microsoft-hosted one?
- When the build needs private-network access, specific hardware, or large persistent caches
- For every build across the org, to cut the per-minute hosted-agent bill
- Only when the deployment target is outside Azure, such as AWS or on-prem
- Whenever the pipeline is authored as YAML in the repository rather than built in the classic visual designer
How does a pipeline enforce a controlled promotion to production?
- With stages targeting environments plus approval checks or gates between them
- By configuring the trigger to run the pipeline only on the main branch
- By running the production job on a dedicated self-hosted build agent reserved for releases
- By disabling pull-request triggers so only merged commits deploy
You got correct