​​Pipelines migreren naar GitHub Actions​

Azure Pipelines vs GitHub Actions: de belangrijkste verschillen

Als je de verschillen vooraf begrijpt, voorkom je later veel extra werk.

Concept	Azure Pipelines	GitHub Actions
Locatie van het pipelinebestand	azure-pipelines.yml (any path)	.github/workflows/*.yml
Syntax voor triggers	trigger:, pr:	on:
Job container	jobs: > job: > steps:	jobs: > <job-id>: > steps:
Herbruikbare taken	Azure DevOps Tasks (marketplace)	Actions (GitHub Marketplace)
Herbruikbare pipelines	Templates (template:)	Reusable workflows (workflow_call)
Secrets	Variable groups / Library	GitHub Secrets op repository-, environment- of organisatieniveau
Environments	Environments met approval gates	Environments with required reviewers
Self-hosted agents	Agent pools	Self-hosted runners / runner groups
Opslag van artifacts	Azure Artifacts	GitHub Packages / Actions artifacts
Matrix builds	strategy: matrix:	strategy: matrix: (zelfdeconcept)

Het goede nieuws is dat GitHub Actions een vergelijkbare syntax gebruikt voor matrix strategies en dat de algemene YAML-structuur grotendeels overeenkomt. De grootste aanpassing zit in de manier waarop steps verwijzen naar actions in plaats van tasks, en hoe secrets en environments zijn ingericht.

 

De opbouw van een GitHub Actions-workflow

name: Build and Test 

on: 
  push: 
    branches: [main] 
  pull_request: 
    branches: [main] 

jobs: 
  build: 
    runs-on: ubuntu-latest 

    steps: 
      - name: Checkout code 
        uses: actions/checkout@v4 

       - name: Set up .NET 
        uses: actions/setup-dotnet@v4 
        with: 
          dotnet-version: '8.x' 

       - name: Restore dependencies 
        run: dotnet restore 

      - name: Build 
        run: dotnet build --no-restore --configuration Release 

      - name: Test 
        run: dotnet test --no-build --configuration Release 

Dit is het GitHub Actions-equivalent van een eenvoudige build in Azure Pipelines. De structuur is overzichtelijk en goed leesbaar. De gebruikte actions, actions/checkout en actions/setup-dotnet, worden officieel onderhouden door respectievelijk GitHub en Microsoft.

 

Azure Pipelines-concepten koppelen aan GitHub Actions

Variables en secrets

In Azure Pipelines definieer je variables rechtstreeks in het pipelinebestand, in variable groups of via de gebruikersinterface wanneer je een pipeline start.

In GitHub Actions:

• definieer je workflow-level variables onder env: op workflow- of jobniveau;
• Secrets are stored in GitHub Secrets (repository, environment, or organisation scope) and accessed via ${{ secrets.MY_SECRET }} 
• Variables (non-secret) can also be stored in GitHub Variables and accessed via ${{ vars.MY_VAR }} 

jobs: 
  deploy: 
    runs-on: ubuntu-latest 
    env: 
      ENVIRONMENT: production 
    steps: 
      - name: Deploy 
        run: ./deploy.sh 
        env: 
          API_KEY: ${{ secrets.API_KEY }} 

 

Environments en approval gates

Azure Pipelines ondersteunt approval gates voordat een stage wordt uitgevoerd. GitHub Actions biedt een vergelijkbaar concept via Environments.

Je maakt een environment aan, zoals production, en configureert hiervoor required reviewers. Zodra een job dit environment gebruikt, wordt de uitvoering gepauzeerd totdat iemand goedkeuring geeft.

jobs: 
  deploy-prod: 
    runs-on: ubuntu-latest 
    environment: production 
    steps: 
      - name: Deploy to production 
        run: ./deploy-prod.sh 
        env: 
          AZURE_CREDENTIALS: ${{ secrets.AZURE_CREDENTIALS }}

 

Herbruikbare workflows 

Met Azure Pipelines templates kun je herbruikbare onderdelen van pipelines definiëren. GitHub Actions gebruikt hiervoor reusable workflows: volledige workflowbestanden die andere workflows kunnen aanroepen via workflow_call.

A reusable workflow (.github/workflows/deploy.yml): 

on: 
  workflow_call: 
    inputs: 
      environment: 
        required: true 
        type: string 
    secrets: 
      AZURE_CREDENTIALS: 
        required: true 

jobs: 
  deploy: 
    runs-on: ubuntu-latest 
    environment: ${{ inputs.environment }} 
    steps: 
      - uses: actions/checkout@v4 
      - name: Deploy 
        uses: azure/webapps-deploy@v3 
        with: 
          app-name: my-app-${{ inputs.environment }} 
          publish-profile: ${{ secrets.AZURE_CREDENTIALS }} 

Zo roep je de workflow aan:

jobs: 
  call-deploy: 
    uses: my-org/my-repo/.github/workflows/deploy.yml@main 
    with: 
      environment: staging 
    secrets: 
      AZURE_CREDENTIALS: ${{ secrets.AZURE_CREDENTIALS }} 

Dit patroon is vergelijkbaar met templates in Azure Pipelines. Het helpt je dubbele code te voorkomen en pipelines binnen de hele organisatie beter beheersbaar te maken.

 

Deployen naar Azure vanuit GitHub Actions

GitHub Actions biedt uitgebreide ondersteuning voor deployments naar Azure. Hiervoor zijn verschillende officieel onderhouden actions beschikbaar:

• azure/login@v2 — voor authenticatie bij Azure via een service principal of OIDC; 
• azure/webapps-deploy@v3 — voor deployments naar Azure App Service;
• azure/container-apps-deploy-action@v2 — voor deployments naar Azure Container Apps;
• azure/aks-set-context@v4 — om verbinding te maken met een AKS-cluster;
• azure/arm-deploy@v1 — voor het deployen van ARM- en Bicep-templates.

OIDC, oftewel OpenID Connect, is de aanbevolen methode voor authenticatie. Hiermee hoef je geen langlevende service principal secrets op te slaan in GitHub Secrets. In plaats daarvan configureer je Azure zodat het de identity provider van GitHub vertrouwt. Tijdens de uitvoering van de workflow worden vervolgens tijdelijke tokens uitgegeven.

- name: Azure Login (OIDC) 
  uses: azure/login@v2 
  with: 
    client-id: ${{ secrets.AZURE_CLIENT_ID }} 
    tenant-id: ${{ secrets.AZURE_TENANT_ID }} 
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} 

Er is geen client secret nodig. De vertrouwensrelatie wordt ingesteld via federated identity credentials op de Azure service principal.

 

Self-Hosted Runners 

Wanneer je pipelines toegang nodig hebben tot een privénetwerk, bijvoorbeeld voor on-premises databases, interne API’s of private Azure-resources, kun je self-hosted runners gebruiken. Deze zijn vergelijkbaar met self-hosted agents in Azure Pipelines. 

Self-hosted runners kunnen bestaan uit:

• afzonderlijke virtual machines die zijn geregistreerd bij een repository, organisatie of enterprise;
• containerised runners die met Actions Runner Controller, of ARC, op Kubernetes draaien.

ARC is de aanbevolen aanpak voor schaalbare, tijdelijke runners.

Met runner groups in GitHub Enterprise bepaal je welke organisaties en repositories specifieke groepen runners mogen gebruiken. Daarmee biedt GitHub een vergelijkbaar governancemodel als de toegangsrechten voor agent pools in Azure Pipelines.

 

Release stages en deployments naar meerdere environments

Een veelgebruikt patroon in Azure Pipelines is een pipeline met meerdere stages: build → deploy naar development → deploy naar staging met goedkeuring → deploy naar production met goedkeuring

In GitHub Actions vertaal je dit naar:

1. Een build job die een artifact produceert;
2. deployment jobs die afhankelijk zijn van de build job via needs: build; en jobs die zijn gekoppeld aan specifieke omgevingen;
3. Environment protection rules met required reviewers voor goedkeuringen.

jobs: 
  build: 
    runs-on: ubuntu-latest 
    steps: [ ... ] 
    outputs: 
      image-tag: ${{ steps.build.outputs.tag }} 

   deploy-dev: 
    needs: build 
    environment: development 
    runs-on: ubuntu-latest 
    steps: [ ... ] 

   deploy-staging: 
    needs: deploy-dev 
    environment: staging 
    runs-on: ubuntu-latest 
    steps: [ ... ] 

  deploy-prod: 
    needs: deploy-staging 
    environment: production 
    runs-on: ubuntu-latest 
    steps: [ ... ] 

 

Tips voor een soepele migratie

• Migreer stapsgewijs: Begin met een nieuwe GitHub Actions-workflow die parallel draait aan de bestaande Azure Pipeline. Stap pas volledig over wanneer je hebt gecontroleerd dat beide dezelfde resultaten opleveren.
• Gebruik de GitHub Actions marketplace: Voor veelvoorkomende taken, zoals het bouwen van Docker-images, uitvoeren van tests en deployen naar cloudservices, is vaak al een onderhouden action beschikbaar.
• Centraliseer gedeelde reusable workflows in een centrale .github repository op organisatieniveau. Zo kunnen meerdere repositories dezelfde workflows gebruiken.
• Gebruik composite actions om meerdere steps binnen een repository te hergebruiken, zonder dat je hiervoor een volledige reusable workflow hoeft te maken.
• Controleer je Azure DevOps service connecties: Inventariseer alle bestaande service connections in Azure DevOps. Voor iedere verbinding moet je bepalen of deze wordt vervangen door een GitHub Secret of, bij voorkeur, een federated credential voor OIDC.

 

Conclusie

Migreren van Azure Pipelines naar GitHub Actions vraagt om meer dan het één op één overzetten van YAML. Toch levert de overstap voor veel teams een overzichtelijker, beter beheersbaar en krachtiger CI/CD-platform op.

Het event-driven model, het uitgebreide aanbod in de GitHub Marketplace en de directe integratie met GitHub-repositories maken GitHub Actions voor veel organisaties een duidelijke verbetering.

In het volgende artikel bekijken we een van de belangrijkste redenen om over te stappen op GitHub Enterprise: de Advanced Security-mogelijkheden die rechtstreeks in het platform zijn geïntegreerd.