Azure DevOps CI/CD for AI-modeller | Steg-for-steg YAML-guide
Vi vet at det kan føles både spennende og utfordrende å sette opp en CI/CD-pipeline for AI-modeller. Sammen tar vi steget fra idé til drift med en robust, Azure-integrert løsning – steg for steg. Automatisering gir trygghet, raskere leveranser og færre overraskelser underveis.
Refleksjon: Hva irriterer deg mest i dagens CI/CD-oppsett for AI-modeller?
1. Hvorfor CI/CD er helt nødvendig for AI-prosjekter
Manuell utrulling av AI-modeller gir ofte
- uforutsigbare datakildeskift som knekker modellen
- versjonskaos når hyperparametere og kode blandes
- uoversiktlige modell-filer og navn
- vanskeligheter med å gjenskape infrastruktur (GPU, Docker-images, Kubernetes)
- skripter som sjelden testes for nøyaktighet, latency eller ressursbruk
Med en CI/CD-pipeline (MLOps) validerer vi hver commit automatisk, versjonerer modelldata entydig og deployer kontrollert uten manuell risiko. Vi er i dette sammen – hver feil er en læringsmulighet.
2. Azure DevOps i korte trekk
I Azure DevOps bruker vi hovedsakelig:
Azure Pipelines for multistage, YAML-definerte CI/CD-flyter
Agent-puljer (Microsoft-hosted og self-hosted GPU/CPU)
Environments med godkjenninger og audit-trail
Artefakter for modellfiler, Docker-images og rapporter
Integrerte tasks for Docker, Kubernetes, Azure CLI, Azure ML, DVC/MLflow
Alt som kode gir full oversikt fra bygg og test til deploy og overvåking.
3. Kodeeksempler: YAML-pipeline
trigger:
branches:
include:
- main
# Trigger-pipeline ved hver commit til main (docs: https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops)
pool:
vmImage: 'ubuntu-22.04'
# Standard Linux-agent. ubuntu-22.04 er eksplisitt og stabilt (docs: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops)
steps:
- task: UsePythonVersion@0
displayName: 'Bruk Python 3.8'
inputs:
versionSpec: '3.8'
architecture: 'x64'
addToPath: true
# Velger og legger Python 3.8 til PATH fra verktøyscache (docs: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/use-python-version-v0?view=azure-pipelines)
- script: |
python -m pip install --upgrade pip setuptools wheel
pip install -r requirements.txt
pytest --maxfail=1 --disable-warnings -q
displayName: 'Installer avhengigheter og kjør tester'
# Oppgraderer pip/verktøy, installerer dependencies og kjører tester
- task: PublishPipelineArtifact@1
displayName: 'Publiser pipeline-artifakter'
inputs:
targetPath: '$(Pipeline.Workspace)'
artifact: 'drop'
publishLocation: 'pipeline'
# Publiserer artefakter til Azure Pipelines for gjenbruk i CD (docs: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/publish-pipeline-artifact-v1?view=azure-pipelines)
Vi inkluderer også
- failover-tester for avhengige tjenester
- sikkerhetsskanning med Trivy eller Snyk
- ytelsestester med begrenset datasett
4. Eksempel på release-pipeline med staging og produksjon
stages:
- stage: Staging
jobs:
- deployment: DeployStaging
environment: 'staging'
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: drop
- task: AzureCLI@2
displayName: 'Registrer modell i Azure ML'
inputs:
azureSubscription: '$(AzureServiceConnection)'
scriptType: bash
scriptLocation: inlineScript
inlineScript: |
az extension add -n ml
az ml model create \
--name myModel \
--version 1 \
--path "$(Pipeline.Workspace)/model.pkl" \
--resource-group "$(ResourceGroup)" \
--workspace-name "$(WorkspaceName)"
- stage: Production
dependsOn: Staging
condition: succeeded()
jobs:
- deployment: DeployProd
environment: 'production'
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: drop
- task: AzureCLI@2
displayName: 'Opprett og oppdater online-endpoint'
inputs:
azureSubscription: '$(AzureServiceConnection)'
scriptType: bash
scriptLocation: inlineScript
inlineScript: |
az extension add -n ml
az ml online-endpoint create \
--name myEndpoint \
--resource-group "$(ResourceGroup)" \
--workspace-name "$(WorkspaceName)" \
--auth-mode aml_token
az ml online-deployment create \
--name blue \
--endpoint-name myEndpoint \
--model myModel:1 \
--instance-type Standard_DS3_v2 \
--instance-count 1
az ml online-endpoint update \
--name myEndpoint \
--resource-group "$(ResourceGroup)" \
--workspace-name "$(WorkspaceName)" \
--traffic-split blue=100
5. Kostnads- og sikkerhetsaspekter
GPU-agenter
- Auto-skalering: steng av idle GPU-agenter etter 30 minutter
- Spot-instances: for eksperimentell trening med akseptabel risiko
- Budsjettvarsler i Azure Cost Management
Service connections
- Azure RBAC: gi minste nødvendige rettigheter
- Lås ned service connection til godkjente pipelines
- Anbefal Key Vault for hemmelighetshåndtering
- Overvåk endringer i Azure Activity Log
6. Anbefalte testmetoder for robusthet
- Enhetstester for kode og datatransformasjon
- Integrasjonstester mot staging-miljø
- Latency- og ressurs-tester for produksjonsmodell
- Failover-tester ved avbrudd i eksterne tjenester
- Sikkerhetstester (penetrasjonstesting, dependency scanning)
7. Modellovervåking og driftstesting
For å sikre kontinuerlig kvalitet i produksjon bør vi
- detektere data-drift med Population Stability Index (PSI) eller Kolmogorov-Smirnov-test (KS-test)
- konfigurere varsler i Application Insights eller Log Analytics ved PSI > 0,1
- inkludere driftstesting som en del av pipeline (f.eks. retraining-trigger ved avvik)
- samle telemetri for latency, feilrate og ressursbruk kontinuerlig
8. Case: kredittscoremodell i bank
Vi fulgte denne prosessen:
- Feature-branch: Data scientist pusher feature/credit-score
- CI kjører: lint → pytest → DVC pull → mini-train → artefakt
- Staging-CD: Docker build/push → AKS deploy → integrasjonstest → manuell godkjenning
- Prod-CD: 10/90 trafikk-splitting → full utrulling
- Overvåking: App Insights varsler ved PSI > 0,1
- Retraining: daglig pipeline kjører trening med ny data
9. Veien videre
- GitOps for ML: deklarer pipelines og infrastruktur som kode
- Serverless-inferens med Azure Functions for sporadiske spørringer
- Feature Stores (Feast, Tecton) i trenings- og deploy-pipen
- Explainable AI-verifisering i CI-steg for forklaringsstabilitet
- Data-drift-triggered retraining med automatiske oppdateringer
Resultat: 25 % raskere utrulling og 40 % færre driftsavvik i første kvartal.
Start med denne malen, tilpass etter egne behov, og opplev hvor raskt dere kan flytte AI-modeller fra idé til pålitelig produksjon. Lykke til!
*Forbehold om kode
Koden i denne guiden er levert som eksempler og utgangspunkt. Den er ikke testet mot alle tenkelige konfigurasjoner eller miljøer. Sørg derfor for å:
Validere og tilpasse alle YAML-filer og skript mot din egen Azure DevOps-instans, agent-pool, resource group, ACR, AKS-kluster og Azure ML-arbeidsområde
Kjøre fullstendige tester – enhet, integrasjon, ytelse og sikkerhet – i egne staging- eller test-miljøer før produksjonssetting
Gjennomføre grundig gjennomgang av service connections, rollebasert tilgang og godkjenningsregler i dine miljøer
Forfatteren påtar seg intet ansvar for uforutsette feil, tap av data, driftsavbrudd eller andre konsekvenser som måtte oppstå ved bruk av eksempelkoden. Leseren bruker den på egen risiko.