Key concepts for new Azure Pipelines users

Key concepts

What is Azure Pipelines?
Overview of Continuous Integration and Continuous Deployment (CI/CD)
YAML Pipelines vs. Classic Pipelines
Pipeline hierarchy: Pipelines → Stages → Jobs → Steps
Agents and agent pools: What runs your pipeline?
Variables and templates for reusability
Triggers: Manual, CI, PR-based
Artifacts: Sharing outputs between jobs or stages
Example YAML pipeline walkthrough

1. What is Azure Pipelines?

Azure Pipelines is a cloud-based continuous integration and continuous delivery (CI/CD) service provided by Azure DevOps. It enables teams to automatically build, test, and deploy code to various environments such as development, staging, and production.

2. Overview of Continuous Integration and Continuous Deployment (CI/CD)

CI (Continuous Integration)

Automates building and testing your code every time you commit changes. It ensures that integration issues are caught early.

CD (Continuous Deployment/Delivery)

Automates the delivery or deployment of your application to staging or production environments after a successful build.

3. YAML Pipelines vs. Classic Pipelines

YAML Pipelines: Defined as code (in .yml files) and stored in your repo. It supports versioning and reuse and is considered modern best practice.
Classic Pipelines: Built via the GUI in Azure DevOps. Good for beginners but less flexible and harder to manage at scale.

4. Pipeline hierarchy: Pipelines → Stages → Jobs → Steps

Pipeline Hierarchy

A trigger tells a pipeline to run.
A pipeline is made up of one or more stages. A pipeline can deploy to one or more environments.
A stage is a way of organizing jobs in a pipeline, and each stage can have one or more jobs.
Each job runs on one agent. A job can also be agentless.
Each agent runs a job that contains one or more steps.
A step can be a task or script and is the smallest building block of a pipeline.
A task is a prepackaged script that performs an action, such as invoking a REST API or publishing a build artifact.
An& artifact is a collection of files or packages published by a run.

5. Agents and agent pools: What runs your pipeline?

An agent is a machine (Microsoft-hosted or self-hosted) that runs the pipeline tasks.
Microsoft-hosted agents: Pre-installed tools, fast to spin up, usage included with Azure DevOps.
Self-hosted agents: You maintain the machine; good for custom tools or restricted environments.
Agent pools: Group agents for sharing across projects or controlling workload.

6. Variables and templates for reusability

Variables: Used for managing configuration (e.g., app name, environment, credentials).
Templates: Allow reuse of steps, jobs, or entire stages across multiple pipelines.

7. Triggers: Manual, CI, PR-based

Triggers define when your pipeline should run:

CI Trigger: Runs on every commit to a branch.
PR Trigger: Runs on pull requests for validation.
Scheduled Trigger: Run pipelines on a timer (e.g., nightly builds).
Manual: Useful for controlled releases or hotfixes.

8. Artifacts: Sharing outputs between jobs or stages

Artifacts are files or packages (e.g., build outputs, test results) produced by one job/stage and consumed by another.

Examples

.zip of your web app
Docker images
NuGet/NPM packages

9. Example YAML pipeline walkthrough

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

stages:
- stage: Build
  jobs:
  - job: BuildJob
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: 'build'
        projects: '**/*.csproj'
        arguments: '--configuration $(buildConfiguration)'

- stage: Deploy
  dependsOn: Build
  condition: succeeded()
  jobs:
  - job: DeployJob
    steps:
    - task: AzureWebApp@1
      inputs:
        appName: 'my-app-service'
        package: '$(Build.ArtifactStagingDirectory)/**/*.zip'