Geschreven door Luuk de Wit

GitHub Actions vs Azure Pipelines

DevOps7 minuten leestijd

Sinds 13 november 2019 is GitHub Actions officieel beschikbaar, de nieuwe CI/CD tool van Github. Nu bijna een half jaar verder, ben ik benieuwd hoe dicht Github Actions naar Azure Pipelines is gegroeid qua functionaliteiten maar ook in hoeverre Github Actions al Azure Pipelines kan vervangen. In dit blog zet ik de belangrijkste verschillen op een rij.

Workflow / Pipeline

Zowel een Github Action workflow als een Azure Pipeline is een configureerbaar geautomatiseerd proces dat bestaat uit één of meerdere "Jobs". Met dit proces bepaal je de CI/CD flow.

In beide gevallen word de YAML syntax gebruikt. Dit word vaak gebruikt voor "Configuration as Code". In dit bestand bepaal je de configuratie van de workflow/pipeline. De locaties van deze bestanden verschilt per oplossing. Bij Azure Pipelines zet je het YAML bestand azure-pipelines.yml in de root folder van het project. Bij GitHub Actions komt deze in de folder /.github/worksflows/<workflownaam>.yml. De YAML bestanden in deze folder worden automatisch opgepakt. Je kan zowel de .yaml of .yml als bestandsextensie gebruiken.

Wil je meer informatie over YAML zie: Learn YAML in five minutes.

Github Actions en Azure pipelines gebruiken voor vergelijkbare stappen soms verschillende benamingen, hieronder een opsomming van de verschillen. Github Actions wordt steeds als eerst genoemd en Azure Pipelines als tweede.

Event / Trigger

Een event / trigger is een activiteit welke de Workflow / Pipeline triggert.

Workflows kunnen net als Pipelines getriggerd worden door het pushen van commits of tags naar specifieke branches in de gekoppelde repository. Maar ook door Pull requests of een scheduled trigger. Naast deze standaard triggers bied Workflows nog een groot aantal activiteiten binnen Github welke de workflow kunnen triggeren.

Kijk voor een lijst van alle Workflow en Pipeline triggers op Workflow Triggers en Pipeline Triggers.

???? / Stage

Azure Pipeline ``stages`` zijn bedoelt om de activiteiten van de pipeline in fases te verdelen. Met gebruik van ``stages`` krijg je de mogelijkheid om de pipeline te pauzeren voor een handmatige check. Bijvoorbeeld wanneer een manager de release van de staging moet goedkeuren voordat deze door mag naar productie.

Github Actions heeft deze mogelijkheid niet.

Job / Job

Zowel Workflows als Pipelines bestaan uit ``jobs``. Een ``job`` bestaat uit één of meerdere ``steps``.

Step / Step

Een ``step`` kan bestaan uit een inline-script of een pre-packaged script. binnen Azure Pipelines ook wel een `task` genoemd. Een pre-packaged script is een `action` in Github Actions.

Action / Task

Een ``action`` of een ``task`` is een vooraf gemaakt script die je aan kan roepen in meerdere Pipelines of Workflows. Zowel Github Actions als Azure Pipelines bied built-in en custom ``actions``/``tasks``.

Het idee achter een custom ``action``/``task`` is het beheer van terug kerende activiteiten te versimpelen. Als je bijv. 10 Workflows of Pipelines hebt met een inline-script waar een aanpassing in nodig is. Zul je al die 10 Workflows/Pipelines moeten wijzigen. Met een ``action``/``task`` hoef je alleen de ``action`` of de ``task`` te wijzigen. De aanpassing is gelijk beschikbaar de eerst volgende keer dat de Pipelines draaien. Hierdoor hoef je niet meer al je Pipelines te wijzigen.

Pipeline ``Tasks`` zijn beschikbaar in de Visual Studio Marketplace. Maar er is ook de mogelijkheid om ze zelf te schrijven.

Community ``Actions`` zijn beschikbaar via de Github Marketplace. Ook ``Actions`` kan je zelf schrijven.

Virtual Environment / Agent

In Github Actions worden ``jobs`` toegewezen aan een ``virtual environment``. Dit kan zowel een Github-hosted of een Self-hosted runner zijn. Je hebt de keuze uit een Windows, Linux of een MacOS enviroment.

Github self-hosted runners zijn nog niet zo heel lang beschikbaar. De belangrijkste verschillen tussen hosted en Github-hosted runners zijn:

Github-Hosted runners bieden een simpelere en makkelijkere manier voor het draaien van workflows. Terwijl self-hosted runners meer configuratie mogelijkheden bieden voor specifieke benodigdheden binnen een workflow.

In Azure Pipelines worden ``jobs`` toegewezen aan ``agent pools``. Een `agent pool` is een groep van gelijke ``agents``. Een ``agent`` kan zowel hosted zijn of self-hosted. Hier heb je dezelfde opties als in Github, Windows, Linux of MacOS.

Voorbeeld Workflow vs Pipeline

Als voorbeeld heb ik een simpele Angular app build pipeline gemaakt voor zowel Github Actions als Azure Pipelines binnen dezelfde repository zodat deze tegelijkertijd triggeren. [^1] Omdat Github Actions nog geen stages ondersteunt heb ik hier geen gebruik van gemaakt. Hierdoor zijn de YAML bestanden makkelijk te vergelijken.

Github Action Workflow

name: Build & Publish Angular in Github Action Workflow
on:
  push:
    branches:
      - master
jobs:
  Build_Angular_App:
    runs-on: ubuntu-latest
steps:
    - uses: actions/checkout@v2   
    - uses: actions/setup-node@v1
      with:
        node-version: 12.16.2
      name: Install Node.js
    - run: |
        npm install
        npm install -g @angular/cli
        npm run lint
        npm run build --prod
      name: npm install and build
    - uses: actions/upload-artifact@v1
      with:
        name: Artifact-GithubActionWorkflow
        path: dist/WorkflowvsPipeline
      name: Publish Artifact

Het resultaat van de bovenstaande Github Actions Workflow:

Azure Pipeline

name: Build & Publish Angular in Azure DevOps Pipeline
trigger:
  - master
jobs:
  - job: Build_Angular_App
    pool:
      vmImage: 'ubuntu-latest'
    steps:  
      - task: NodeTool@0
        inputs:
          versionSpec: '12.16.2'
        displayName: 'Install Node.js'
      - script: |
          npm install
          npm install -g @angular/cli
          npm run lint
          ng build --prod
        displayName: 'npm install and build'
      - task: PublishPipelineArtifact@0
        inputs:
          artifactName: 'Artifact-AzurePipeline'
          targetPath: 'dist/WorkflowvsPipeline'
        displayName: 'Publish Artifact'

Het resultaat van de bovenstaande Azure Pipeline:

De belangrijkste verschillen

  • Azure Pipelines ondersteunt voor nu nog de classic editor, hoe lang deze nog beschikbaar blijft is onbekend. De classic editor bied de mogelijkheid om je CI configuratie in een GUI te definiëren in plaats van een YAML bestand. Github Actions heeft geen GUI editor en ondersteunt alleen YAML.
  • Azure Pipelines heeft een marketplace met veel kant en klare Pipelines en extensies. Ook Github Actions heeft een marketplace, maar is nog niet zo uitgebreid als die van Azure Pipelines. Dit zegt nu nog weinig omdat Github Actions nog redelijk nieuw is. Dit zal de aankomende tijd gaan veranderen doordat de github actions community verder zal groeien.
  • Azure Pipelines is minder strikt in de YAML structuur. Je kan bijv. taak definities weglaten wanneer je Pipeline maar uit één taak bestaat. Je hoeft dan niet de taak te definiëren, alleen de stappen zijn dan genoeg. Github Actions bied deze mogelijkheid niet.
  • Azure Pipelines ondersteunt ``stages ``, dit is zowel in de Classic editor als YAML beschikbaar. Stages bied de mogelijkheid om deployment workflows in verschillende fases op te delen. Bijv. Build -> Test -> Staging -> Prod.

Github Actions bied deze mogelijkheid niet.

Kan ik Azure Pipelines vervangen door Github Actions?

Om eerlijk te zijn is het antwoord afhankelijk van de functionele eisen. Hoe complex je Workflow/Pipeline moet worden en of je afhankelijk bent van handmatige goedkeuringen van bijv. een manager. Dit verschilt natuurlijk per project.

Als je nog geen Azure Pipelines gebruikt maar wel al Github gebruikt als code repository, en je hebt geen manual approvals nodig, dan is Github Actions de juiste keuze om mee te beginnen.

Mocht je wel al gebruik maken van Azure Pipelines i.c.m. Github Repositories dan zou je bijv. je code kwaliteit checks naar Github Actions kunnen verplaatsen die dan weer je Azure Pipeline triggert wanneer de code voldoet aan alle voorwaarden.

Github Actions is de afgelopen maanden hard gegroeid, en is naast Azure Pipelines een mooie toevoeging aan de bestaande CI/CD tooling. Hou er rekening mee dat er nog vol aan Github Actions ontwikkeld wordt, dit kan betekenen dat de huidige "tekortkomingen" er over een paar maanden niet meer zijn.

Heb je vragen of opmerkingen? Laat het gerust weten!

[^1]: https://github.com/Luukxt8/workflowvspipeline