Comparing GitHub Actions and Azure Pipelines: High-level concepts
GitHub Actions is GitHub's new CI/CD platform (currently in open beta, at the time of writing). It is comparable with Microsoft's other CI/CD offering, Azure Pipelines, which forms part of the Azure DevOps suite.
Being fairly well acquainted with Azure Pipelines, I found myself looking for comparisons when getting started with GitHub Actions. It became clear that both platforms are built on the same fundamentals (and technology), so it was quite easy to get going with GitHub Actions.
In this post, I will go over the similarities and differences in the high-level concepts and terminology between the two platforms. Each section header is in the format <GitHub Action concept> / <Azure Pipeline concept>. I will use abbreviations GHA and AP to refer to GitHub Actions and Azure Pipelines, respectively.
(N.B. This post covers concepts for the new YAML based Azure Pipelines, rather than the classic Build & Release Pipelines)
Workflow / Pipeline
The top-level concept in GHA is the Workflow. This is the process that defines how you run your CI/CD steps. The equivalent concept in AP is the Pipeline. Both Workflows and Pipelines are made up of one or more Jobs, and can be triggered by activities. These activities are known as Events in GHA and Triggers in AP.
Both *Workflows *and Pipelines are defined using YAML files.
Event / Trigger
These are the activities that trigger a *Workflow *or Pipeline run. Both GHA and AP support triggering from either pushing to specific branches or tags in the associated repository, from pull requests, or on a defined schedule.
However, GHA also supports triggering from a whole range of activities that occur on GitHub, such as forking the repo, creating an issue, or a new release being created. The full list of Events can be seen here.
Job / Job
Both Workflows and Pipelines are made up of Jobs. A Job is collection of Steps. AP additionally has the concept of Stages, which are logical groupings of Jobs that you can define in the Pipeline. There is no equivalent concept in GHA.
In both platforms, a Job is the smallest process you can assign to be executed, where all the Steps in the job will share a compute context (*Virtual Environment *for GHA, Agent for AP) and filesystem.
Step / Step
A *Step *is the smallest building block of a *Pipeline *or *Workflow. *Both GHA and AP allow to you specify either an inline script for your Step, or a pre-packaged script, known as Actions for GHA and Tasks for AP.
Action / Task
Actions/Tasks are pre-created scripts that can be used in a Step.
In AP, Tasks come from either the set of built-in catalogue of tasks or from the Visual Studio Marketplace (either public or your own private marketplace).
In GHA, Actions can come from a GitHub repository (either the same repo as the Workflow, or a public repo), or from a Docker container image published in a public registry. Actions can be built using either Docker containers or JavaScript. The Docker-based Actions can only be run on a Linux Virtual Environment, whereas the JavaScript-based actions can run on Linux, Windows, or MacOS.
Virtual Environment / Agent
In AP, Jobs are run on an Agent, which is an installable piece of software. Instead of assigning jobs to a specific *Agent, *you assign it to an agent pool, which is a collection of similar Agents. Microsoft provides hosted agents, running Windows, Linux, or MacOS, or you can create your own self-hosted agents, either in the cloud or on-prem.
In GHA, Jobs are assigned to a *Virtual Environment. *These are GitHub-hosted virtual environments for Windows, Linux, and MacOS. More information on the virtual environments can be found here. GHA does not currently offer any self-hosted option.
