This an excerpt of an article written for Microsoft Tech Community Blog. To read the whole article click here
Introduction
When starting in Azure DevOps Pipelines one can immediately become inundated with terminology that may seem foreign or question what pipeline structure will lead to the most flexibility and streamlining of their build/deployment process. This post will focus on the hierarchy of Tasks->Jobs-Stages. My intent will be to cover Environments and Variables in a follow up post and then templating in one after that.
What is a Pipeline?
An Azure DevOps Pipeline is the next generation of what is today referred to as Classic Build and Releases. I have heard them called YAML Pipelines, Multi-Stage Pipelines, and just Pipelines. They have been around now for a few years; however, with the maturity and introduction of new features coming from the product team the general direction seems to be towards adopting pipelines. Perhaps none more telling than the option to “disable classic pipelines” in an Azure Devops Organization.
At the end of the day a pipeline is defined in YAML and used to build and/or deploy your code. Some of the features of YAML pipelines are:
- Defined in Source Control via YAML Files
- Can be templated
- Reference resource in other repositories (even GitHub)
- Easily run jobs in parallel
- Self-Hosted or MS Hosted Agents (Machines) for execution
For more information feel free to check out Microsoft’s official documentation.
If coming from a GitHub background this may sound familiar to you as it is comparable to GitHub Actions. Here is a breakdown of terminology between the two. For more feel free to check out this comparison document from GitHub
| Azure DevOps Pipeline | GitHub Action |
| pipeline | workflow |
| stages | stages (separate workflow files) |
| jobs | jobs |
| tasks | uses |
Here is an example of how one environment could utilize stages, jobs, tasks:
