Promote a validated model through an Azure DevOps pipeline into an Azure ML online endpoint with smoke tests, approvals, and controlled traffic shifting.
This lab teaches the last mile of MLOps: taking a checked model and releasing it safely instead of copying files around and hoping it works.
This is like opening a new restaurant branch with inspections, limited opening hours, and backup plans before a full public launch.
The deployment pipeline consumes a validated model version, applies endpoint configuration, runs smoke tests, and optionally uses staged traffic movement such as canary deployment. Azure DevOps provides the orchestration and audit trail. Azure ML provides the endpoint and deployment target.
stages:
- stage: deploy_staging
jobs:
- job: deploy_model
steps:
- script: az ml online-deployment create --file deployment.yml
- script: az ml online-endpoint invoke --name churn-endpoint --request-file sample.json
- stage: deploy_prod
dependsOn: deploy_staging
condition: succeeded()
az ml online-endpoint create --name churn-endpoint --file endpoint.yml az ml online-deployment create --name blue --endpoint churn-endpoint --file deployment.yml az ml online-endpoint update --name churn-endpoint --traffic blue=100
A pricing model is deployed to staging after validation. Azure DevOps sends test payloads and confirms response shape, latency, and logging. After approval, production receives 10% of traffic for 30 minutes. Only when KPIs remain healthy does traffic move to 100%.
Write a mini release checklist for a high-risk model: validation report attached, smoke test passed, staging latency below threshold, approver named, rollback target identified, production traffic set to 10% first. Then note which of those are currently manual and which should be enforced automatically.
Problem: the pipeline says deployment is complete, but the endpoint returns schema errors to real clients.
It confirms the endpoint can serve a basic known request after deployment.
Staging reduces risk by checking the deployment in a controlled environment first.
Approvals create accountability and prevent accidental promotion of risky releases.
Canary traffic is a small percentage of live traffic sent to the new version first.
Because failures happen fastest when teams are least ready to improvise safely.
Validation metrics, smoke test results, drift context, rollback target, and business risk notes.
Because smoke tests may not represent real traffic shapes, payload variety, or scale.
Deploy success means infrastructure changed successfully; release success means live behavior is acceptable.
Scriptable traffic changes are repeatable, auditable, and easier to reverse quickly.
Equating model registration with production readiness and skipping real deployment checks.
Stop promotion, roll back traffic, and investigate business-impact metrics rather than waiting for more harm.
Automation provides evidence quickly, but high-risk business decisions still require accountable human judgment.
Look at region-specific configuration, endpoint routing, environment variables, and resource quotas.
Expand test payload coverage to include real edge cases and production-like schemas.
It includes approvals, smoke tests, controlled traffic, and rollback design, which are core production concerns.
Production model deployments in finance, retail, and SaaS often use exactly these patterns: staged rollout, automated checks, and formal approval gates before full exposure.
This lab converts a validated artifact into a controlled release. Safe deployment is where MLOps proves it is engineering, not just experimentation.