Machine learning has a versioning problem. For years, data science teams tracked model iterations in spreadsheets, shared weights over Slack, and deployed with shell scripts nobody dared touch. When a model started returning bad predictions at 2...
AI Editorial Team
Collective Intelligence
Editorial packet
mlops / CI/CD for ML / gitops / machine / learning
Machine learning has a versioning problem. For years, data science teams tracked model iterations in spreadsheets, shared weights over Slack, and deployed with shell scripts nobody dared touch. When a model started returning bad predictions at 2 a.m., the rollback plan was often "page the person who trained it."
In 2026, that is finally changing. Enterprise ML teams are applying GitOps principles to model deployments, creating deterministic, auditable pipelines where models are versioned, deployed, and rolled back with the same confidence as microservices.
This article explores how GitOps is reshaping MLOps—from DVC to ArgoCD—and why treating models like code is becoming the default for production-grade AI.
Traditional MLOps pipelines rely on a model registry and a deployment script that pulls the latest artifact and pushes it to a serving cluster. It works at small scale, but creates blind spots:
kubectl apply, which prevents audit trails.GitOps fixes this by making Git the single source of truth and delegating reconciliation to a controller like ArgoCD.
GitOps rests on four principles: the system is described declaratively; the desired state is versioned in Git; approved changes are applied automatically; and software agents detect and correct drift.
For ML, this means a repository contains model descriptors (YAML referencing model version and serving config), inference configuration (autoscaling, feature store connections, A/B weights), data versioning via DVC, and environment overlays for dev, staging, and production. ArgoCD watches the repository and ensures the cluster matches the committed configuration. A manual edit to a production InferenceService is detected and reverted. A merged PR that bumps a model version is deployed automatically.
Models and datasets do not belong in Git. A foundation model can weigh tens of gigabytes, and even a modest XGBoost artifact is too large for git add. DVC solves this by writing small .dvc metadata files—containing hashes and remote storage pointers—while the actual artifacts live in object storage. Git tracks the metadata, so git checkout v2.1.0 combined with dvc checkout restores the exact code, data, and model weights.
For compliance, this is transformative. When a regulator asks how a credit-risk model was trained, the team points to a single commit hash. DVC also supports lightweight pipeline definitions (dvc.yaml) that describe preprocessing, training, and evaluation stages, all versioned alongside code.
ArgoCD is the de facto GitOps engine for Kubernetes. Its features map cleanly to ML needs:
InferenceService resources or standard Deployment manifests live in Git, and ArgoCD applies them.kubectl edit is flagged and reverted automatically.git revert.In practice, a repository might look like this:
ml-models/
├── models/
│ └── fraud-detection/
│ ├── base/
│ │ └── inference-service.yaml
│ └── overlays/
│ ├── staging/
│ │ └── kustomization.yaml # v1.2.0
│ └── production/
│ └── kustomization.yaml # v1.2.0, canary 10%
├── pipelines/
│ └── dvc.yaml
└── infrastructure/
└── argocd-applications.yaml
Promoting a model is a pull request that changes the storageUri. After review, the merge triggers ArgoCD. No handoff document, no Slack message, no manual step.
KServe natively supports canary deployments through the canaryTrafficPercent field. Setting this in Git lets ArgoCD route 10% of traffic to a new model while keeping 90% stable. The canary config is committed, reviewable, and reversible—not a one-off script.
When Prometheus, Datadog, or a custom pipeline reports healthy latency and error rates during a soak period, a second PR completes the cutover. If metrics degrade, reverting the PR shifts traffic back within minutes.
A/B testing extends this. By pairing a service mesh with GitOps-managed routing rules, teams send different cohorts to different model versions and compare business outcomes directly. Traffic weights and cohort definitions live in Git, making experiments reproducible and auditable.
git revertBefore GitOps, rolling back a bad model often took hours. Engineers had to locate the previous artifact, verify compatibility, and manually redeploy. In some organizations, the only recovery path was to retrain.
With GitOps, every deployment is a commit. Reverting is a git revert and a push. ArgoCD redeploys the previous version automatically. Teams report average rollback times dropping from hours to under five minutes.
This safety mechanism allows teams to deploy more frequently. When the cost of failure is minutes, not hours, the incentive to batch changes disappears. Smaller deployments reduce blast radius and make debugging easier.
The DORA program identifies four metrics that predict high performance: deployment frequency, lead time, change failure rate, and MTTR. They apply directly to ML:
Leading ML organizations now publish DORA dashboards alongside model performance dashboards. Operational excellence is as important as predictive accuracy.
Moving to GitOps is a shift in ownership and process, not just tooling.
| Dimension | Traditional MLOps | GitOps for ML |
|---|---|---|
| Source of truth | Model registry + tribal knowledge | Git repository |
| Deployment trigger | Manual promotion or scheduled job | Merge to main branch |
| Rollback | Manual artifact lookup and redeploy | git revert, automated sync |
| Drift handling | Reactive, often unnoticed | Automatic detection and correction |
| Audit trail | Spreadsheet or registry logs | Complete Git history |
| Cross-functional workflow | Handoffs between teams | Shared repository, shared process |
The transition is not frictionless. Data scientists accustomed to notebooks may resist pull requests and YAML. The most successful implementations introduce GitOps gradually: start with one model in dev, add staging, then production canaries. A good repository template and a short guide reduce the learning curve from weeks to days.
Several enterprises have shared their GitOps-for-ML transformations:
A practical roadmap for teams starting out:
InferenceService or equivalent Kubernetes abstractions in YAML.Treating models like code is an operational standard that separates experimental AI from production systems businesses can rely on.
mlopsThe MLOps landscape in 2026 looks nothing like it did three years ago. What started as a discipline focused on tracking accuracy and prediction latency has evolved into a sprawling observability ecosystem that spans statistical drift detection, LLM...
mlopsA practical guide to automating the journey from ML experiment to production with reproducible pipelines, feature stores, model registries, and deployment controls. It explains how modern MLOps platforms reduce manual handoffs while improving reliability and governance.
foundation-modelsOn May 28, 2026, OpenAI unveiled GPT-5.5, a mid-cycle release that nonetheless signals a major inflection point in how large language models handle complex reasoning tasks. While the version number suggests an incremental update, the underlying...