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@1
displayName: 'Bruk Python 3.12'
inputs:
versionSpec: '3.12'
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 aifoundry model upload \
--name myModel \
--version 1 \
--path "$(Pipeline.Workspace)/model.pkl" \
--resource-group "$(ResourceGroup)" \
--project-name "$(ProjectName)"
- 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)" \
--project-name "$(ProjectName)" \
--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)" \
--project-name "$(ProjectName)" \
--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.
Endringslogg: juni 2026
- «Sist oppdatert»-dato lagt til
- CI-pipeline: UsePythonVersion@0 → UsePythonVersion@1, Python 3.8 → Python 3.12
- CD Staging og Produksjon: --workspace-name "$(WorkspaceName)" → --project-name "$(ProjectName)"
- Kryss-lenker til de tre øvrige DevOps-artiklene lagt til under «Les også»