Nordlicht Reisen GmbH, a fictional travel agency, has its booking portal in a GitHub repository. The team that maintains the payment integration, however, works with boards and pipelines in Azure DevOps and wants to keep its builds there. You are to decide which tool takes over the delivery of the portal, connect the repository to Azure Pipelines and decide when which pipeline starts. These are the skills of this lesson: select a deployment automation solution, connect GitHub repositories to Azure Pipelines and write trigger rules for pipelines.
Prior knowledge: How a workflow in GitHub Actions is built is in K3, lesson 3.7.1. How a YAML pipeline in Azure Pipelines for a GitHub repository comes about, with agent, template and variable group, is in K3, lesson 3.7.2. In each of them you build one way. This lesson starts one level above: you choose between the ways, tie the worlds together and control when a run starts.
Choosing a solution
What the two tools have in common
Both build, test and deliver, both read a YAML file from the repository, both know jobs, steps, variables, secrets and reuse. That is why the question is rarely "what can one do that the other cannot". The question is: where do code, people and permissions already live, and what does switching cost?
GitHub's guide to migrating from Azure Pipelines to GitHub Actions names where the tools differ:
| Topic | Azure Pipelines | GitHub Actions |
|---|---|---|
| Editor | there is also the classic graphical editor | according to GitHub "does not support a graphical editor" |
| Stages | keyword stages in one file |
according to GitHub, stages must go into separate workflow files (structure with several jobs and needs: see lesson 4.3) |
| Order of jobs | dependsOn |
needs |
| Conditions | condition with functions such as eq() |
if with operators such as == |
| Scripts | script, bash, pwsh or task inputs |
all scripts go under run, shell selects the shell |
| Default shell on Windows | the command prompt cmd.exe | PowerShell |
| Selecting your own machine | capabilities of the agent | labels of the runner |
| Reusable building blocks | tasks | actions, found in the GitHub Marketplace |
Two rows of this table carry decisions. If you want to see the stages and checks of a delivery in one file, Azure Pipelines has the keyword for it. If you port a pipeline, note that Azure Pipelines can fail on a write to stderr while, according to the guide, GitHub does not support that, and that the default shell on Windows is a different one.
Combining instead of deciding
You do not have to choose one tool for everything. For the action Azure/pipelines, Microsoft describes as an example using GitHub Actions for continuous integration and Azure Pipelines for continuous deployment, to use features such as approvals, environments and the close integration with Kubernetes. The action starts a pipeline in Azure DevOps from a workflow; according to its page, it takes the project URL, the name of the pipeline and a personal access token (PAT) of the organization as inputs. The example is in the section "Connecting both worlds".
The criteria
Five questions put a decision in order. Every answer is an observation about your team, not a property of a tool:
- Where does the code live? If it is on GitHub, pull request, checks and workflow are in one place. If it is in Azure Repos, the result of the pipeline stays tied to the same permissions and work items.
- Who maintains checks and approvals? Environments with checks and approvals are the topic of lesson 4.7; in Azure Pipelines they work in YAML, on GitHub through environments with protection rules.
- How much compute time does the run need, and who pays for it? The models differ (lesson 4.2).
- Which building blocks do you need? Tasks for Azure Pipelines, actions for GitHub Actions: check whether both sides cover your goals.
- Which administration already exists? Organizations, permissions and pools have to be maintained separately in both worlds (module D5).