From CI/CD to continuous training
MLOps Pipelines — Kubeflow & Argo
Turn training scripts into production pipelines: Argo Workflows, Kubeflow Pipelines, experiment tracking with MLflow, and GitOps-driven continuous training with Argo CD.
What you'll learn
Module 1From CI/CD to ML Pipelines
- Why ML Breaks Classic CI/CD
- Anatomy of a Training Pipeline
- Pipelines as DAGs: Artifacts, Lineage & Caching
- The Tooling Landscape: Where Kubeflow & Argo Fit
- Experiment Tracking & Model Registries
- Knowledge Check
Module 2Argo Workflows: The Pipeline Engine
- Architecture: CRDs, Controller & Executor
- Templates & DAGs: Writing Your First Workflow
- Passing Data: Parameters & Artifacts
- Resilience: Retries, Timeouts & Exit Handlers
- Triggering: CronWorkflows & Argo Events
- GPU Steps on Shared Clusters
- Knowledge Check
Module 3Kubeflow Pipelines
- Kubeflow: Platform vs. Pipelines
- How Python Becomes Pods
- Writing Components
- Composing Pipelines
- Runs, Experiments & Recurring Runs
- Operating KFP in Production
- Knowledge Check
Module 4GitOps for ML: Argo CD & the Continuous-Training Loop
- GitOps Fundamentals with Argo CD
- Repo & Environment Layout for ML
- Promoting a Model: Registry to Production
- Progressive Delivery for Models
- Closing the Loop: Drift-Triggered Retraining
- Observability for Pipelines
- Knowledge Check
Preview the first lesson
The core shift: in classic CI/CD you version and ship one kind of artifact — code. An ML system ships three: code, data, and the trained model. Your pipeline discipline (build → test → deploy on every commit) still applies, but a model can go stale without a single line of code changing, because the world that produced the training data changed. That is why ML adds a third leg to CI/CD: CT — continuous training.
What actually changes
Triggers multiply. A classic pipeline runs on git push. An ML pipeline also runs on: new labeled data landing in a bucket, a scheduled retrain (cron), a drift alert from production monitoring, or a manual experiment. Your orchestrator must accept all of these, not just webhooks from the git forge.
Tests become statistical. A unit test is binary; a model evaluation is a metric (accuracy, F1, AUC) compared against a threshold and against the currently deployed model. "Did the build pass?" becomes "is the candidate at least as good as the champion on the holdout set, and not worse on any protected slice?" This gate — often called model validation — is the ML equivalent of your test stage, and it must be automated or CT is impossible.
Reproducibility gets harder. Rebuilding a binary from a git SHA is deterministic. Reproducing a model requires pinning the code SHA, the exact data snapshot, the hyperparameters, the base image (CUDA/driver/framework versions), and the random seeds. Every serious pipeline records all of these as lineage metadata for each run.
Failure modes are silent. A crashed deployment pages you. A drifting model serves confident, wrong predictions with HTTP 200. Monitoring must therefore watch prediction quality and input distributions, not just latency and error rate — and feed back into the retraining trigger. That feedback loop is the whole game in mature MLOps.
In practice: everything you know from DevOps transfers — pipelines as code, immutable artifacts, promotion through environments, GitOps. The delta you are learning in this course is (1) an orchestrator that can run DAGs of heavyweight, GPU-hungry steps on Kubernetes (Argo Workflows, Kubeflow Pipelines), and (2) the ML-specific stages — data validation, training, evaluation gates, model registry — that slot into it.
AI tutor on every page
Ask questions in context — the tutor reads the exact lesson you're on.
Hands-on terminal labs
Realistic scenario labs with a simulated cluster — no setup required.
Shareable certificate
Pass the Knowledge Checks to earn a verifiable certificate of completion.