Vijf diensten onder één naam

Azure DevOps is geen enkele tool maar een verzameling diensten die je los kunt gebruiken. Voor data engineering heb je er in de praktijk drie van nodig, en de andere twee kom je vooral tegen in teams die er al mee werken.

• Repos — Git-repositories met pull requests en branch policies. Hier staat je dbt-project, je notebooks of je Terraform.
• Pipelines — bouwen, testen en uitrollen. Dit is waar je de meeste tijd doorbrengt.
• Artifacts — pakketten en build-uitvoer bewaren. Voor data vooral handig om Python-wheels of dbt-artefacten tussen pipelines door te geven.
• Boards — werk plannen met backlogs en sprints.
• Test Plans — handmatig testbeheer. Bij datawerk zelden gebruikt.

Organisatie, project en repository

De hiërarchie is drie lagen diep. Een organisatie is je bedrijf. Daarbinnen maak je projecten, en elk project heeft zijn eigen repositories, pipelines en boards. Rechten regel je op projectniveau.

Voor een datateam werkt één project met meerdere repositories meestal prettiger dan een project per repository: je pipelines kunnen dan makkelijk templates en variabelengroepen delen.

Een vertakkingsmodel dat bij datawerk past

De meeste datateams zijn klein en leveren vaak. Daar past trunk-based development beter bij dan een zwaar model met release- en hotfixbranches: je werkt op korte takken vanaf main en voegt dagelijks samen.

Wat je vooral wilt vermijden is een tak die weken openstaat. Bij transformatiecode leidt dat gegarandeerd tot conflicten, want iedereen raakt dezelfde modellen aan.

Branch policies: de knop die het verschil maakt

Een repository zonder beleid op main is een netwerkmap met versiegeschiedenis. Met branch policies dwing je af dat er niemand rechtstreeks naar main duwt en dat elke wijziging langs een pull request gaat.

Zet minimaal deze drie aan: minstens één reviewer, een build die moet slagen, en gekoppelde werkitems. De eerste zorgt dat iemand meekijkt, de tweede dat kapotte code main niet haalt, de derde dat je over een jaar nog kunt achterhalen waarom een model eruitziet zoals het eruitziet.

# Altijd vanaf een actuele main beginnen
git checkout main
git pull

git checkout -b feature/1234-omzet-per-segment

# ... je wijzigingen ...
git add models/marts/fct_omzet_segment.sql
git commit -m "Omzet per klantsegment toegevoegd aan de gold-laag"
git push -u origin feature/1234-omzet-per-segment

# Pull request aanmaken vanaf de opdrachtregel
az repos pr create \
  --title "Omzet per klantsegment" \
  --description "Nieuwe mart voor de kwartaalrapportage. Tests toegevoegd." \
  --source-branch feature/1234-omzet-per-segment \
  --target-branch main \
  --work-items 1234
        

Wat hoort niet in je repository

Bij datawerk is de verleiding groot om even een CSV of een exportje mee te committen. Doe dat niet: Git is er niet voor gemaakt en je krijgt het er nooit meer uit. Een .gitignore die profielen, omgevingsbestanden en data buitensluit, hoort bij het aanmaken van de repository.

# Inloggegevens
profiles.yml
.env

# Door dbt gegenereerd
target/
dbt_packages/
logs/

# Data hoort niet in git
*.csv
*.parquet
*.xlsx
!seeds/*.csv          # behalve seeds: die zijn klein en bewust beheerd

# Python
__pycache__/
.venv/
        

Pipelines als code

Azure DevOps kent twee soorten pipelines. De klassieke stel je samen in de webinterface; de YAML-variant staat als bestand in je repository. Kies altijd YAML. Je pipeline gaat dan mee in pull requests, je ziet in de historie wie wat wijzigde, en je kunt hem terugdraaien zoals elke andere code.

trigger:
  branches:
    include: [main]
  paths:
    include: [models/**, macros/**]   # alleen starten als dit wijzigt

pr:
  branches:
    include: [main]

pool:
  vmImage: ubuntu-latest

variables:
  - group: dbt-gedeeld          # variabelengroep uit Library
  - name: pythonVersie
    value: '3.11'

stages:
  - stage: Controleren
    displayName: Bouwen en testen
    jobs:
      - job: dbt_build
        steps:
          - task: UsePythonVersion@0
            inputs:
              versionSpec: $(pythonVersie)

          - script: pip install dbt-snowflake==1.8.3
            displayName: dbt installeren

          - script: dbt deps
            displayName: Pakketten ophalen

          - script: dbt build --target ci
            displayName: Modellen bouwen en testen
            env:
              SNOWFLAKE_PASSWORD: $(snowflakeWachtwoord)
        

Templates tegen kopieerwerk

Heb je drie repositories die bijna dezelfde stappen draaien, zet die stappen dan in een template. Wijzig je de dbt-versie, dan doe je dat op één plek in plaats van drie.

# In het template
parameters:
  - name: doelomgeving
    type: string
  - name: selectie
    type: string
    default: ''

steps:
  - script: pip install dbt-snowflake==1.8.3
    displayName: dbt installeren
  - script: dbt deps
    displayName: Pakketten ophalen
  - script: |
      dbt build --target ${{ parameters.doelomgeving }} ${{ parameters.selectie }}
    displayName: Bouwen en testen

# In de pipeline die het template gebruikt
steps:
  - template: templates/dbt-stappen.yml
    parameters:
      doelomgeving: ci
      selectie: '--select state:modified+'
        

Wat valt er te testen aan data?

Bij applicatiecode draai je unittests. Bij transformatiecode ligt het anders: de logica zit in SQL en het resultaat hangt af van de data. Toch is er genoeg te controleren voordat iets main haalt.

• Compileert het? Draait dbt compile zonder fouten, dan klopt in elk geval je Jinja en je verwijzingen.
• Slagen de tests? Je unique, not_null en relationships uit dbt draaien hier.
• Is de stijl consistent? Een linter als SQLFluff voorkomt discussies over opmaak in reviews.
• Blijft het bestaande werken? Door alleen wat je wijzigde plus alles erachter te bouwen, zie je of je iets stuk hebt gemaakt.

stages:
  - stage: CI
    jobs:
      - job: controleren
        steps:
          - task: UsePythonVersion@0
            inputs:
              versionSpec: '3.11'

          - script: pip install dbt-snowflake==1.8.3 sqlfluff
            displayName: Gereedschap installeren

          - script: dbt deps
            displayName: Pakketten ophalen

          # Artefacten van de laatste productierun binnenhalen,
          # zodat we weten wat er gewijzigd is ten opzichte van productie
          - task: DownloadPipelineArtifact@2
            inputs:
              buildType: specific
              project: $(System.TeamProject)
              definition: $(prodPipelineId)
              artifactName: dbt-artifacts
              targetPath: $(Pipeline.Workspace)/prod-artifacts
            continueOnError: true

          - script: dbt compile --target ci
            displayName: Compileren

          - script: sqlfluff lint models/ --dialect snowflake
            displayName: Stijlcontrole
            continueOnError: true        # waarschuwen, niet blokkeren

          - script: |
              dbt build --target ci \
                --select state:modified+ \
                --defer --state $(Pipeline.Workspace)/prod-artifacts
            displayName: Gewijzigde modellen bouwen en testen
            env:
              SNOWFLAKE_PASSWORD: $(snowflakeWachtwoord)

          - task: PublishTestResults@2
            condition: always()          # ook publiceren als de stap faalde
            inputs:
              testResultsFormat: JUnit
              testResultsFiles: target/*.xml
        

Een schone omgeving per pull request

Laat je CI niet in hetzelfde schema bouwen als je collega's. Geef elke pipelinerun een eigen schema op basis van het build-id, en ruim het achteraf op. Dan kunnen twee pull requests tegelijk draaien zonder elkaar te overschrijven.

variables:
  - name: ciSchema
    value: 'ci_pr_$(System.PullRequest.PullRequestId)'

steps:
  - script: dbt build --target ci
    env:
      DBT_SCHEMA: $(ciSchema)

  # Opruimen, ook als de build faalde
  - script: |
      echo "DROP SCHEMA IF EXISTS $(ciSchema) CASCADE;" | snowsql -f -
    displayName: CI-schema opruimen
    condition: always()
        

Van merge naar productie

Een merge naar main hoort niet automatisch productie te raken. Tussen die twee zit een uitrol die je wilt kunnen tegenhouden, inzien en terugdraaien. Daarvoor gebruik je environments met approvals.

Een environment in Azure DevOps is meer dan een naam: het is de plek waar je vastlegt wie moet goedkeuren, op welke momenten er niet uitgerold mag worden, en wat de geschiedenis van uitrollen is.

stages:
  - stage: Acceptatie
    dependsOn: CI
    condition: succeeded()
    jobs:
      - deployment: naar_acc
        environment: acceptatie
        strategy:
          runOnce:
            deploy:
              steps:
                - checkout: self
                - script: dbt build --target acc
                  env:
                    SNOWFLAKE_PASSWORD: $(accWachtwoord)

  - stage: Productie
    dependsOn: Acceptatie
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - deployment: naar_prod
        environment: productie      # hier hangt de approval aan
        strategy:
          runOnce:
            deploy:
              steps:
                - checkout: self
                - script: dbt build --target prod
                  env:
                    SNOWFLAKE_PASSWORD: $(prodWachtwoord)

                # Artefacten bewaren, zodat de volgende CI kan vergelijken
                - publish: target/
                  artifact: dbt-artifacts
        

Approvals en checks

Op een environment hang je meer dan alleen een goedkeuring. De nuttigste voor datateams:

• Approvals — een of meer mensen moeten akkoord geven. Zet er een toelichting bij zodat de goedkeurder weet waar hij ja op zegt.
• Business hours — alleen uitrollen binnen een venster. Handig om te voorkomen dat er vrijdagmiddag om vijf uur iets live gaat.
• Exclusive lock — maar één uitrol tegelijk naar deze omgeving. Dit voorkomt dat twee runs elkaars tabellen overschrijven.
• Invoke REST API — bijvoorbeeld eerst controleren of het nachtelijke laadproces klaar is.

Waar wachtwoorden horen

Nooit in je YAML. Alles in je repository is zichtbaar voor iedereen met leesrechten en blijft voorgoed in de historie staan, ook nadat je het eruit haalt. Er zijn drie betere plekken.

• Variabelengroepen in Library, met de waarde als secret gemarkeerd. Prima voor losse wachtwoorden.
• Azure Key Vault, gekoppeld aan een variabelengroep. De waarde staat dan op één plek voor je hele organisatie en je kunt rouleren zonder je pipelines aan te raken.
• Service connections met een workload identity. Dan is er helemaal geen wachtwoord meer.

variables:
  - group: snowflake-prod       # gekoppeld aan Key Vault

steps:
  # GOED: als omgevingsvariabele doorgeven
  - script: dbt build --target prod
    env:
      SNOWFLAKE_PASSWORD: $(snowflakeWachtwoord)

  # FOUT: in de opdrachtregel zelf. Dat belandt in de logs
  # en is zichtbaar voor iedereen die de run kan bekijken.
  # - script: dbt build --password $(snowflakeWachtwoord)
        

Service connections

Een service connection is de brug tussen je pipeline en een externe dienst: een Azure-abonnement, een Databricks-workspace, een container registry. Voor Azure gebruik je bij voorkeur workload identity federation: je pipeline wisselt dan een kortlevend token in en er is geen geheim meer om te beheren of te lekken.

Door Microsoft gehost of zelf beheerd

Een door Microsoft gehoste agent is een schone machine die na afloop verdwijnt. Dat is prettig: geen onderhoud, geen resten van een vorige run. Er zijn twee redenen om toch een eigen agent te draaien.

De eerste is netwerktoegang. Staat je bron achter een firewall of in een virtueel netwerk, dan komt een gehoste agent er niet bij. De tweede is wachttijd: met één parallelle job staan je pipelines in de rij, en een eigen agent lost dat op.

# Door Microsoft gehost
pool:
  vmImage: ubuntu-latest

# Eigen agent, bijvoorbeeld binnen je netwerk
pool:
  name: eigen-agents
  demands:
    - agent.os -equals Linux
    - dbt           # zelf gezette eigenschap

# Per stage verschillen kan ook: CI gehost, productie op eigen agent
stages:
  - stage: CI
    pool:
      vmImage: ubuntu-latest
  - stage: Productie
    pool:
      name: eigen-agents