Start with the big picture: what it does, where it lives, and the three letters that define it.

Azure Pipelines is a cloud service that automatically builds, tests, and deploys your code. It is one part of a bigger product family called Azure DevOps Services, which also includes places to store code (Repos), plan work (Boards), manage test cases (Test Plans), and share software packages (Artifacts). Pipelines can be used on its own, and it works with code stored almost anywhere: Azure Repos, GitHub, Bitbucket, or any other Git server. It also works with nearly any language and target: Java, .NET, Python, JavaScript, Go, mobile apps, containers, and more, on Windows, Linux, and macOS, deploying to Azure, other clouds, or your own servers.

Three terms sit at the heart of the idea. Continuous integration, shortened to CI, means that every time someone changes the code, the system automatically builds the program and runs tests, so problems are found within minutes instead of weeks. Continuous delivery means that every change that passes the tests is automatically prepared and made ready to release, so that releasing is a routine button press rather than a nervous event. Continuous deployment, the third idea, goes one step further and releases to users automatically without any button press. Both of the last two are abbreviated CD, which causes endless confusion, so context matters. Together the practice is called CI/CD.

A short history

In the early 2000s, teams built software on a single “build server” in a cupboard, often babysat by one person. Microsoft offered build tools in Team Foundation Server, a product installed on a company’s own machines. When the cloud arrived, Microsoft moved these ideas online as Visual Studio Team Services, and in 2018 renamed the family Azure DevOps, with Azure Pipelines as its build and release engine. Around the same time, Microsoft made Pipelines free for open source projects and added support for GitHub, which helped it spread far beyond the Microsoft world. Since then, the biggest shift has been from clicking together pipelines in a visual editor to writing them as text files that live next to the code. Microsoft also owns GitHub Actions, a similar service, and many organizations use one or both. We compare them later.

Every tool exists because something hurt. Here is the pain that Azure Pipelines removes.

Picture a team of ten developers building a shopping website. Each person changes different parts of the code on their own computer. Without automation, a typical week looks like this. On Monday someone builds the program on their laptop and it works. On Wednesday a colleague builds it on theirs and it fails, because their laptop has a different version of some tool. On Friday the team joins everything together for the first time, and a hundred small conflicts appear at once, a painful event nicknamed integration hell. Releasing to customers happens once a month, late at night, with a long checklist of manual steps, and every release is a risk. When something breaks in production, nobody is quite sure which change caused it.

Automation fixes each of these. A pipeline builds the code the same way every time, on a clean machine, so “it works on my machine” stops being an excuse. It runs tests on every change, so problems are found while the change is still fresh in the author’s mind. It deploys using the same scripted steps to every environment, so releases are boring and repeatable. And it keeps a full record of what was built, tested, approved, and deployed, so every release can be traced back to the exact code that created it.

Azure Pipelines has a small set of building blocks. Learn these words and every diagram becomes easy to read.

The central object is the pipeline: the full automated process, from a code change to a result. Each time a pipeline starts, that is a run. A pipeline is organized as a set of boxes inside boxes. The biggest boxes are stages, the major phases such as Build, Test, and Deploy. Inside a stage are jobs, groups of work that run together on one machine. Inside a job are steps, the individual actions, one after another. A step is either a task, a ready-made, packaged action such as “run the .NET build” or “deploy to an Azure web app,” or a script, a few lines of your own commands.

Now let us see how the pieces connect, from your code to the system that runs it.

Azure Pipelines has two big sides. The service side, hosted by Microsoft in the cloud, is the brain. It stores your pipeline definitions, watches for triggers, decides what should run and in what order, keeps the queue of waiting jobs, stores logs and results, and handles permissions and approvals. The agent side is the muscle. An agent is a small program running on a machine, which could be a virtual machine that Microsoft manages for you or a computer of your own. It asks the service, “Do you have any work for me?” When there is a job waiting, it downloads the steps, executes them, and sends back the logs and results.

Two details are worth noting. First, the agent pulls work from the service. The service does not push into your network. For self-hosted agents, this means you only need to allow outbound connections to Azure DevOps, with no inbound holes in your firewall. Second, the service never needs to see your running application. It only coordinates, while the agent does the real work next to your code and your tools.

flowchart LR
    DEV["Developer pushes code"] --> REPO["Code repository"]
    REPO -->|"trigger event"| SVC["Azure Pipelines service"]
    SVC --> Q["Job queue"]
    Q --> POOL["Agent pool"]
    POOL --> A1["Agent 1"]
    POOL --> A2["Agent 2"]
    A1 --> ART["Artifacts and packages"]
    A2 --> ENV["Deployment environments"]
    A1 -.->|"logs and results"| SVC
    A2 -.->|"logs and results"| SVC
    

Read the diagram from left to right. A developer pushes code to the repository. The repository tells the service that something changed. The service checks the pipeline definition, creates a run, and puts the jobs in a queue. Idle agents in the matching pool pick jobs up, execute their steps, and send results back. Along the way, finished files are saved as artifacts, and deployment jobs reach out to the environments where the software will live.

There are two ways to describe a pipeline. One of them is now strongly preferred.

The modern way is a YAML pipeline. YAML is a simple, human-readable text format that uses indentation to show structure, a little like an outline. You write the pipeline as a text file, usually named azure-pipelines.yml, and store it in the same repository as your code. Because it is just a file in the repository, it enjoys all the benefits that code has. It has a full history, so you can see who changed the pipeline and why. It can be reviewed through a pull request like any other change. It lives on branches, so a new idea can be tried on a branch without disturbing the main line. And it travels with the code, so an old version of the code is built by the old version of the pipeline. This idea is called pipeline as code.

The older way is the classic editor, a visual designer where you click to add tasks and fill in forms. Classic pipelines come in two kinds: build pipelines, which compile and test, and release pipelines, which deploy. They are easy to start, but they live inside the service, not next to your code, so they are harder to review, copy, and reproduce. Microsoft encourages new work to use YAML, which now handles both build and deployment through multi-stage pipelines, and classic release pipelines are considered the legacy approach.

The three nested boxes decide what runs in sequence and what runs side by side.

A stage is a logical phase and the main way to organize a pipeline. By default, stages run one after another, but you can describe dependencies so that some stages run in parallel, or one stage waits for two others. Each stage can have conditions, such as “run only on the main branch,” and can contain approvals and checks, which we meet later.

A job is a collection of steps that run on one agent. Jobs in the same stage run in parallel by default, as long as enough agents are free, and you can add dependencies when order matters. A special job type, the deployment job, targets an environment and keeps a history of what was deployed. Every job starts with a clean slate on its agent, so a later job cannot see files from an earlier one unless you pass them through artifacts. This clean-slate rule surprises many beginners, and it is also what keeps builds repeatable.

A step is the smallest unit: a task or a script. Steps inside a job run strictly in order, and by default a failing step stops the job. A step can be marked to run even after a failure, which is useful for clean-up actions such as shutting down a test database. Jobs can also use a matrix strategy, a feature that repeats the same job for several combinations of settings, for example building on three versions of a language and two operating systems, six copies in all, running in parallel.

flowchart LR
    subgraph B["Stage - Build"]
      B1["Job - compile and unit test"]
      B2["Job - code analysis"]
    end
    subgraph T["Stage - Test"]
      T1["Job - integration tests"]
    end
    subgraph D["Stage - Deploy staging"]
      D1["Deployment job"]
    end
    subgraph P["Stage - Deploy production"]
      P1["Deployment job after approval"]
    end
    B --> T --> D --> P
    

The agent is where your code really builds. Choosing the right kind of agent affects cost, speed, and security.

An agent pool is a group of agents. A job asks for a pool, and any free agent in that pool can take it. There are several kinds of agents.

Microsoft-hosted agents

These are virtual machines that Microsoft prepares and runs for you. They come with a wide set of common tools preinstalled: compilers, language runtimes, Docker, cloud tools, and more, available on Ubuntu Linux, Windows, and macOS images. Each job gets a brand-new machine that is thrown away when the job ends. This gives you clean, repeatable builds and removes any maintenance. The trade-offs are that you cannot install permanent software on them, they cannot reach servers sitting inside your private network by default, and they start from a cold state each time, so downloads and restores must be repeated unless you use caching.

Self-hosted agents

These are machines that you own and run, whether physical computers, virtual machines in Azure or elsewhere, or containers. You install the agent program and register it in a pool. Because you control them, they can have special tools, powerful hardware, graphics cards, or access to private networks and on-premises systems. They keep their disk between jobs, which can speed up builds by reusing downloaded files. The cost is that you must patch, secure, and scale them yourself.

Scale set agents and managed pools

For large teams, an agent pool backed by a virtual machine scale set automatically adds and removes self-hosted virtual machines as the queue grows and shrinks, and can reset each machine after use. A newer option, Managed DevOps Pools, lets Microsoft handle much of this scaling and maintenance while the machines run inside your own Azure subscription and network. This gives you private network access with less hands-on work.

A pipeline is only a description until something starts it. Triggers are the starters.

A trigger decides when a pipeline runs. Several kinds exist, and one pipeline can use more than one at the same time.

Triggers can be narrowed with filters. A branch filter says which branches count, such as only the main branch and release branches. A path filter says which folders matter, so that a change to the documentation does not start a full build of the application. Skipping a run for a message such as a tag in the commit is also possible, and a batch option groups several quick pushes into one run, which saves capacity when many developers push at once.

The pull request check deserves special attention. By adding a build validation policy to a branch in your repository, you can require that the pipeline passes before a change may be merged. This turns the pipeline from a helpful tool into a gatekeeper that protects the main branch from broken code.

flowchart LR
    T1["Push to branch"] --> P["Pipeline run"]
    T2["Pull request opened"] --> P
    T3["Nightly schedule"] --> P
    T4["Another pipeline completes"] --> P
    T5["New package or image"] --> P
    T6["Manual run"] --> P
    

What actually happens, step by step, between a developer pressing save and a green tick appearing?

Let us follow one push. A developer sends a change to the repository. The repository notifies Azure Pipelines through a connection called a webhook, which is simply a message sent automatically when something happens. The service finds the pipeline definition for that branch and reads it. If the definition uses templates from other places, the service pulls those in and combines everything in a step called expansion. It then checks the triggers and filters. If the change matches, the service creates a run and breaks it into stages and jobs, working out which can start first.

For each job that is ready, the service looks at what pool and what machine type it asks for, and places the job in a queue. It also checks whether you have enough parallel jobs, the number of jobs your organization is allowed to run at the same moment. If all slots are busy, the job waits. When a slot and an agent are free, an agent receives the job. For Microsoft-hosted agents, a fresh virtual machine is prepared. The agent downloads the steps, checks out the source code from the repository, and runs each step in order, streaming the log lines back to the service as they appear, which is why you can watch a run live in your browser.

When the job ends, the agent reports the result: succeeded, failed, canceled, or partially succeeded. The service records it, saves the logs and any published artifacts, and decides what comes next. If the next stage depends on this one, it now becomes ready. If there is an approval waiting, the service pauses and notifies the approvers. The agent’s machine is deleted if it was Microsoft-hosted. At the end of the last stage, the run is marked complete and the final status is sent back to the repository, where it appears as a tick or cross beside the change.

sequenceDiagram
    participant Dev as Developer
    participant Repo as Repository
    participant Svc as Pipelines service
    participant Ag as Agent
    participant Env as Environment
    Dev->>Repo: Push code
    Repo->>Svc: Webhook notifies change
    Svc->>Svc: Read definition and create run
    Svc->>Ag: Offer queued job to free agent
    Ag->>Repo: Check out source code
    Ag->>Ag: Run steps in order
    Ag-->>Svc: Stream logs and send result
    Svc->>Env: Start deployment job after checks
    Svc-->>Repo: Report status tick or cross
    

The same pipeline must work for many settings. Variables and parameters make that possible without copying the pipeline.

A variable is a named value that a pipeline can use in its steps, such as the name of a server, a version number, or a build configuration. Variables can be defined inside the pipeline file, in the portal, or created while a run is going. The service also provides many built-in variables describing the run itself: the name of the branch, the number of the build, the folder where the source code was placed, and the identity of who started it. Using these avoids typing the same facts in many places.

A variable group is a named collection of variables stored in the shared library of a project, and many pipelines can use the same group. It is the right place for values that are shared by several pipelines, such as the address of a test database. A variable group can be linked to Azure Key Vault, a locked cabinet for secrets in Azure. The pipeline then reads secrets from the vault at the moment a run starts, so the secrets are never copied into the pipeline service for long-term storage.

A runtime parameter is different. It is a value that the person starting the run can choose, such as which environment to deploy to or whether to skip a slow test. Parameters have a type, such as text, number, true or false, and can offer a fixed list of allowed choices, which appear as a form in the portal when someone runs the pipeline. Because parameters are decided when the pipeline is expanded, they can even change the shape of the pipeline, for example by deciding whether a whole stage appears.

How secrets are protected

A variable marked as secret is encrypted in the service and its value is masked in logs, shown as stars. Secret variables are deliberately not passed to scripts automatically. You must map a secret into a step explicitly, which makes it harder to leak by accident. Remember, though, that masking is a courtesy, not a guarantee. A script that you allow to run can still transform a secret, such as printing it with spaces between the letters, and defeat the mask. Never run untrusted code in a pipeline that has access to important secrets.

The difference between a beginner’s pipeline and a professional one is reuse. Templates let a hundred projects share one good design.

A template is a piece of pipeline definition stored in its own file, which other pipelines can include. Instead of copying twenty lines for building a web application into every project, you write them once as a template and each project refers to it, passing in parameters for the few things that differ. When you improve the template, every project that uses it improves too. Templates come in several sizes: a step template holds a few steps, a job template holds a whole job, a stage template holds a stage, and a variable template holds a set of variables. Templates can include other templates, so a stage template might use job templates that use step templates, like nesting dolls.

Templates can live in the same repository, or in a shared repository maintained by a platform team and referenced by many teams. A shared repository lets an organization publish its approved building blocks, such as “how to build and scan a container image” or “how to deploy to our Kubernetes clusters.” Versions of templates can be pinned using branches or tags, so that a change in the template does not break every pipeline at once.

Templates as guardrails

Templates are also a powerful tool for governance, which means keeping everyone within safe rules. In an extends template, the pipeline is not allowed to define its own structure. Instead it must extend a master template written by the security or platform team. The master decides which steps are mandatory, such as vulnerability scanning and compliance checks, and what teams can customize, such as the application’s build commands. You can then add a required template check to protected resources such as a production environment or a service connection, so that only pipelines extending the approved template may use them. A team cannot quietly remove the scan step, because the resource refuses pipelines that do not follow the template.

flowchart TB
    PT["Platform team approved template"] --> S1["Mandatory scan step"]
    PT --> S2["Mandatory compliance check"]
    PT --> SLOT["Team supplied build steps"]
    APP1["Team A pipeline extends template"] --> PT
    APP2["Team B pipeline extends template"] --> PT
    PT --> PROD["Production environment - requires template"]
    

Because every job starts clean, you need ways to pass files forward and to avoid repeating slow work.

A pipeline artifact is a file or folder that a run saves so that later jobs and stages can use it, or so that people can download it. For example, the Build stage compiles the application and publishes the result as an artifact named “drop.” Every later stage downloads exactly this same artifact. This is the key to a core rule of good delivery: build once, deploy many. The same tested package that went to the test environment should go on to staging and production, rather than being rebuilt at each step, because a rebuild could differ in tiny ways and make your testing meaningless.

Azure Artifacts is a related service that hosts packages, which are reusable pieces of code that your programs depend on or that you share between teams. It supports common formats such as NuGet, npm, Maven, Python, and a general-purpose universal format. A feed is a private store of packages with its own permissions. Teams publish internal libraries to a feed, and pipelines pull them back when building other projects. A feed can also act as a safe proxy to public registries and keep a copy of the public packages you used, which helps protect you if a public package is removed or tampered with.

Caching saves time. Most builds begin by downloading the same dependencies, such as hundreds of libraries, that did not change since the last run. A cache task stores a folder, such as the downloaded libraries, under a key that is based on the files that describe your dependencies. When the key matches on a later run, the folder is restored in seconds instead of downloaded again. When the dependency list changes, the key changes, and a new cache is saved. This is especially valuable on Microsoft-hosted agents, which start from nothing on every job.

A pipeline that builds but does not test only proves the code compiles. Tests prove it works.

Tests come in layers, often drawn as a pyramid. At the wide base are unit tests, tiny and very fast checks of single functions, which run in seconds and can number in the thousands. In the middle are integration tests, which check that parts work together, such as the application talking to a real database. At the narrow top are end-to-end tests, which drive the whole system like a user would, clicking through a browser. Higher tests are slower and more fragile, so a healthy suite has many unit tests and few end-to-end tests. Other checks add safety: static analysis reads code for mistakes and style problems without running it, security scans look for known vulnerabilities in your code and in the libraries you use, and performance tests check speed under load.

Azure Pipelines understands the results of common test tools. A publish test results step reads the output files, and the run page then shows how many tests passed and failed, which tests are new failures, and how long each took. Code coverage reports show what fraction of the code the tests actually exercised. The results flow back to the pull request page, so reviewers see a failing test beside the change that caused it. Over time, the service tracks test trends and can flag flaky tests, which sometimes pass and sometimes fail on the same code without any change.

Getting the package to users safely is where pipelines earn their keep.

An environment is a named target for deployment, such as Test, Staging, or Production. It is more than a label. An environment keeps a history of every deployment to it, showing which run, which commit, and who approved it. It can hold resources, such as a Kubernetes namespace or a group of virtual machines, so that the pipeline can see what it is deploying onto. And, importantly, an environment is where you attach approvals and checks, the gates that stop a deployment until a rule is satisfied.

The job that deploys to an environment is a deployment job. It supports deployment strategies, different recipes for rolling out a change with less risk.

flowchart LR
    NEW["New version"] --> C1["Canary - 5 percent of users"]
    C1 --> CHK["Check errors and speed"]
    CHK -->|"healthy"| C2["Grow to 50 percent"]
    C2 --> C3["Roll out to 100 percent"]
    CHK -->|"unhealthy"| RB["Roll back to old version"]
    

Deployment strategies provide lifecycle hooks, which are named points where you can place your own steps: before deployment, during it, after traffic is routed, and then separate steps for on success and on failure. For example, a failure hook can restore the previous version and send an alert. For web apps in Azure App Service, deployment slots let you deploy to a hidden twin of the live site, warm it up, test it, and then swap the twin into place, which gives zero downtime and a one-click swap back.

To deploy into Azure or push to a registry, the pipeline needs permission. Service connections are how that permission is held and controlled.

A service connection is a saved, secure link between your Azure DevOps project and an outside system. Examples include an Azure subscription, a container registry, a Kubernetes cluster, GitHub, or a package server. A pipeline never receives the underlying credential in plain sight. It refers to the connection by name, and the service passes the access to the right task at the right moment. Each connection has its own permissions: which pipelines may use it, and which users may edit it.

For connections to Azure, the older way was a service principal with a secret, which is an identity in Microsoft Entra ID with a password-like value. The weakness is that the secret expires, must be rotated, and could leak. The modern and recommended way is workload identity federation. Here the pipeline proves its identity to Entra ID using a short-lived signed token, through a standard called OpenID Connect, and Entra ID is configured to trust that exact pipeline. Nothing secret is stored, nothing expires silently, and the access the pipeline receives is short-lived. For self-hosted agents running on Azure virtual machines, a managed identity offers a similar secret-free route.

A pipeline can change your production systems. That power makes it a target, and a place where good rules pay off.

Think of security in layers. The first layer is who may change the pipeline. Because pipeline files live in the repository, branch policies and code review protect them: nobody should be able to push a change to the main pipeline file without review. The second layer is protected resources. Environments, service connections, variable groups, agent pools, and secure files can each be marked as protected and carry checks that every run must pass before it may use them.

Threats worth knowing

Code from forks. On public projects, strangers can propose changes from their own copies of your repository. By default, secrets are not given to builds of such changes, and you should keep it that way. Injection. If a pipeline builds a command from text that a user controls, such as a branch name or a pull request title, a clever attacker may sneak extra commands into it. Treat these values as untrusted data, never paste them directly into scripts. Supply chain attacks. A tampered library or build tool can slip into your build. Pin versions, use your private feed as a proxy, scan dependencies, and prefer trusted tasks from verified publishers. Over-privileged pipelines. A pipeline that can do everything gives an attacker everything. Use the setting that limits the job authorization scope, so that a run can only touch resources in its own project.

flowchart TB
    CODE["Code change by developer"] --> PR["Pull request review and branch policy"]
    PR --> RUN["Pipeline run from approved branch"]
    RUN --> CHK["Environment checks - approval, branch, template"]
    CHK --> CONN["Service connection with least privilege"]
    CONN --> PROD["Production deployment"]
    RUN -.-> LOG["Audit log and run history"]
    

Pipelines fail for many reasons, and good ones fail clearly, safely, and recoverably.

Start by understanding the result of a run. A run can succeed, fail, be canceled, or end partially succeeded, which means everything that was required passed, but some step marked as allowed to fail did not. Each step and job can have a timeout, the longest it may run before the service stops it, and it is wise to set a realistic limit. Otherwise a hung job may hold an agent and a parallel slot for hours. Tasks can be given a retry count to try again after a failure, which helps with short problems such as a brief network glitch while downloading a package.

Use conditions to control what runs after trouble. A clean-up step can be set to run always, whether the earlier steps passed or not, such as removing a temporary test environment so it does not keep costing money. A notification step can run only on failure. When a stage fails after a long time, you do not need to start over: you can often rerun failed jobs or rerun from the failed stage, saving the work that already succeeded.

Failure scenarios and recovery

A healthy delivery system is one you can see into. Pipelines give you several windows.

The first window is the run page. For every run you can see the stages and jobs as a live diagram, open the log of each step, download all logs, and read the summary of tests, artifacts, and linked work items. When a step fails, the log shows the exact command and error. For deeper detail, you can run with system diagnostics turned on, which prints extra information about what the agent is doing, though it can reveal more than you want, so use it carefully.

The second window is analytics. Pipeline reports show the pass rate, the average duration, and the time spent in each stage and task over weeks and months. A pipeline that slowly grows from ten minutes to forty is a problem you can spot early. You can also see how often tests fail, which tests are flaky, and how long jobs wait in the queue for an agent. The third window is notifications and service hooks. Notifications send email when runs fail or approvals wait. Service hooks send events to chat tools such as Teams or Slack, ticket systems, or your own web address, so that the right people hear about a failed production deployment within moments.

The fourth window concerns agents and pools. You can watch how many agents are online, how busy they are, and how many jobs are waiting. For self-hosted agents, also monitor the machines themselves: disk space, memory, and operating system updates. A full disk on a build machine is a classic cause of mysterious failures.

Measures that tell the real story

Researchers who study software delivery, in a body of work known as DORA metrics, found four numbers that distinguish strong teams: deployment frequency, how often you release; lead time for changes, how long from a code change to production; change failure rate, what share of releases cause trouble; and time to restore service, how quickly you recover. Your pipeline records the data needed for the first two and helps with the others, so it is a natural place to measure them.

Azure Pipelines is priced by how much work can run at the same time, not by how many minutes you use in total.

The key unit is the parallel job. One parallel job lets one job run at a time. If you have two parallel jobs, two jobs can run side by side, and a third must wait in the queue. You buy parallel jobs separately for Microsoft-hosted agents and for self-hosted agents. Public projects usually get generous free capacity, and private projects typically get a small free grant that can be limited in minutes per month, so it is wise to check the current terms for your organization on the official pricing page.

Beyond the free grants, you pay a monthly price for each extra parallel job. Self-hosted parallel jobs are cheaper than Microsoft-hosted ones, because you also provide and pay for the machines yourself. Related services, such as Azure Artifacts storage beyond a free amount and user licenses for Azure DevOps, are priced separately.

Developers wait for pipelines. A faster pipeline means faster feedback, happier teams, and more frequent releases.

There are five main ways to speed things up. First, run in parallel: split independent work into separate jobs, and use a matrix to run test groups at the same time. Second, cache dependencies and build outputs so that unchanged work is not repeated. Third, do less: use branch and path filters, shallow clones that fetch only recent history, and incremental builds that rebuild only what changed. Fourth, order smartly: put fast checks first so that obvious failures stop the run early. Fifth, choose the right agent: a bigger machine, or a self-hosted agent that keeps its tools and caches warm between runs, can cut minutes from every run.

Before changing anything, measure. The run page shows how long each step took. Often a single step, such as downloading packages or running one slow test suite, takes half of the total time. Fix the biggest slice first. Be careful about parallelism, too: more jobs mean more parallel slots consumed, and splitting a small job adds start-up overhead for each piece.

Teams that have run thousands of pipelines keep finding the same good ideas and the same traps.

A short checklist of what experienced teams do, and the slips that cost beginners the most time.

Mistakes that cost the most

There are several good tools for automation. The right choice depends on where your code lives and what you need.

Many organizations use more than one. A common pattern is to keep source code on GitHub and use Azure Pipelines for build and deployment, because it connects well to GitHub while adding environments and approvals. Microsoft invests heavily in GitHub Actions too, so it is sensible to check current guidance on which service best fits new projects, and to avoid moving pipelines just for fashion. Moving has a real cost, and a working, well-designed pipeline is worth keeping.

Three stories show how the pieces fit together in daily practice.

A good architect knows both where a tool shines and where it does not.

A simple decision guide

Azure Pipelines is an automated assembly line for software. A change goes in, and a tested, traceable, deployable package comes out.

We started with the bakery idea: the same careful steps, run by machines, in the same order every time. We then met the hierarchy of pipeline, stage, job, and step; the agents that do the work; the triggers that start it; and the life of a single run from webhook to final status. We looked at variables, templates, artifacts, caching, testing, and deployment strategies. We saw how service connections, identity federation, checks, and approvals keep power under control, and how monitoring, retries, and clean-up keep the system dependable. Finally we compared costs, patterns, and alternatives, so that you can decide when this tool fits.