# mlops-for-devops teaches MLOps through the pipeline you already know > mlops-for-devops is a two-phase, project-based MLOps curriculum that teaches platform and SRE engineers by building an employee attrition model for a 500,000 person organisation, with code in the repository and the walkthroughs published as separate guides. **techiescamp/mlops-for-devops** — MLOps for DevOps Engineers - A hands-on, project-based guide to Machine Learning Operations - Repository: https://github.com/techiescamp/mlops-for-devops - Website: https://devopscube.com/devops-to-mlops/ - Stars: 545 · Forks: 242 - Language: Python - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/techiescamp-mlops-for-devops ## The curriculum inverts the usual MLOps audience mlops-for-devops is a hands-on, project-based guide to machine learning operations written for DevOps, platform and SRE engineers, and its central bet is stated plainly: most MLOps resources are written for data scientists learning infrastructure, and this one flips that around. The framing analogy is engineering work rather than science. The argument is that you do not need to become a data scientist, and that understanding how an ML model is built, trained and served makes you better at operating ML workloads in production, in the same way that understanding how a Java application is built makes you a better DevOps engineer even though you do not write the application. That is a coherent position, and it is also a marketing claim, so the way to judge the course is by whether the steps are reproducible. The repository itself is a table of contents with links, which means the quality of the teaching lives in the guides it points to rather than in the files next to this README. ## One attrition model carries the whole roadmap The course picks a single use case and refuses to change it: employee attrition prediction for a large organisation of roughly 500,000 employees, built from your local systems in the first phase. The stated reason is focus. Keeping one problem end to end keeps the attention on infrastructure and operations rather than on data science theory. The arc is deliberately the same shape as a normal DevOps onboarding. Phase one starts with the basics of building and training a classic ML model, which is the part a platform engineer usually has the largest gap in, and works up to production-ready MLOps. The framing is that an MLOps engineer does not need to be a data scientist, and that understanding the workflow is what lets you build, automate, deploy and troubleshoot these systems. The two phases are mirrored in the repository as the phase-1-local-dev and phase-2-enterprise-setup directories, with a third platform-tools directory alongside them. A capstone that combines everything into a production-style MLOps platform is listed as planned rather than delivered, which is worth knowing before you plan a curriculum around the whole series. ## Phase one ends with a model behind a live API The first phase has four steps, each with its own guide. Step one is the project dataset pipeline, step two is the data preparation stages, step three is training and building the prediction model, and step four is going from the model to a live API with KServe. The shape of that sequence is the useful part. It deliberately starts at the data layer, where the work looks like pipeline engineering, and ends at the serving layer, where the work looks like a deployment. A reader who has run services in production will recognise the milestones even before understanding the modelling in between. The serving step is the one that lands hardest for a DevOps audience, because KServe is a Kubernetes custom resource for model inference, and the mechanics of that are platform work rather than modelling work. The step list does not include a separate feature engineering or experiment tracking stage, which is consistent with the phase boundary, since those arrive in phase two as dedicated guides. ## Phase two is twelve guides over the operational surface The second phase replaces local and manual ML workflows with automated and production-ready ones, and it covers six named areas: a data versioned workflow, automated data pipelines, scalable training pipelines, experiment tracking, scalable model deployment, and model monitoring. The twelve guides expand those areas one at a time. Data versioning is split into fundamentals, a hands-on DVC with AWS S3, and a versioned pipeline built with Airflow on Kubernetes. Feature stores get a conceptual guide followed by a hands-on Feast on Kubernetes. Kubeflow appears three times, as an explanation, as a hands-on install of Kubeflow Pipelines on Kubernetes, and as Kubeflow Trainer. Experiment tracking is covered by MLflow, deployment by a KServe guide, and monitoring by an explanation of model monitoring followed by a hands-on piece using Evidently AI on Kubernetes. The ordering is a curriculum, not a reference. Reading the explanation before the hands-on piece is what turns twelve links into a course, and the phase two code sits in the phase-2-enterprise-setup directory. ## The stack is Kubernetes, and the tools are named The tech stack table is short and specific about what the course assumes. Data pipeline work is Python with Airflow. Model training is scikit-learn. Serving is FastAPI, Flask, Docker and KServe. Orchestration is Kubeflow and MLflow Pipelines. Monitoring is Evidently AI. Infrastructure is Kubernetes with Helm. Everything in the roadmap runs on Kubernetes and Docker, and the README is explicit that these are the tools used in real-world MLOps platforms, which is a claim about relevance rather than a benchmark. A separate list names tools the course points at without covering in depth, which is worth reading as a signpost rather than as part of the path: Ray as an open-source distributed computing framework for Python and AI workloads, CML for CI/CD on machine learning projects, Dagster as a cloud-native data pipeline orchestrator, Kestra as an orchestration platform for data, AI and infrastructure workflows, and Flyte as AI orchestration in pure Python. The recommended reading is broader still, with the Google MLOps whitepaper, a Volkswagen end-to-end MLOps platform case study on AWS, and a write-up on moving Discord from a single node to multi-GPU clusters. ## What the repository holds, and what it links to The top-level entries are a .gitignore, the LICENSE file, the README, a licenses directory, and three code directories: phase-1-local-dev, phase-2-enterprise-setup and platform-tools. There is no application code, no Dockerfile at the root and no deployment manifests to read at a glance, because the substance of each step is in the linked guide and the code in the repository is the working material that goes with it. That structure has a consequence for how you use the course. Each guide is published as a separate article, several on a newsletter platform and a couple on the project site, and the phase one steps sit behind newsletter links while the DevOps to MLOps guide is a separate introductory read recommended for people completely new to the field. The guides are where the explanations live, so the repository alone is a map, and treating it as a self-contained curriculum would mean missing most of the content. The repository also asks for stars, with a note aimed at people learning MLOps with it. That is worth mentioning only because it tells you the intended user: a learner working through the course sequentially rather than a maintainer looking for a component. ## The dual licence is unusual for a course The licensing here is not a single thing, and it is the detail most likely to surprise someone who assumes a public repository means open content. The project is dual licensed, with the code, meaning scripts, configs and manifests, under Apache 2.0, and the content, meaning the README, the guides and the docs, under All Rights Reserved. A commercial licensing contact address is given for anyone who needs the content licensed. The practical reading is that you can fork, run and adapt the manifests and scripts under a permissive licence, but you cannot redistribute the written guides as your own course, and the writing on the project site is the same kind of asset. This is why the repository's licence field is recorded as a custom licence that GitHub cannot classify, since a standard SPDX identifier cannot express a code-plus-content split. If you are building internal training from it, the code is the part you can use freely, and the guides are the part to think about. ## Where this is the wrong resource The clearest case is a data scientist. Every concept here is introduced through a DevOps analogy, and a reader who already knows what a feature store or an experiment tracker is will spend their time working through a narrative written for someone who does not. The second case is an engineer who wants a deployable reference rather than a curriculum. There is no ready-made MLOps platform to clone and adapt; the repository holds phase code, and the walkthroughs are instructions to follow. If your goal is to run a production ML platform this month, a reference implementation would serve you better than a course that spends phase one on data preparation. The third limitation is the capstone, which is listed as planned. The full arc from a local pipeline to an enterprise platform is not in the repository yet, so a team hoping to learn from a complete end-to-end example will be disappointed by the current state of it. The maintenance picture supports the same caution. There are no GitHub releases, the last push was on 2026-09-15, and the guides are edited on a publication schedule rather than versioned with the code, so if you are following along, expect the written steps and the repository contents to drift apart occasionally. ## Conclusion mlops-for-devops fits a DevOps, platform or SRE engineer who is about to own ML infrastructure and wants the mental model of the ML workflow explained in infrastructure terms rather than in modelling terms, and who can work through a guided project rather than read and skip. It does not fit a data scientist, who does not need the analogies, and it is the wrong choice if you need a reference implementation you can lift, since the walkthroughs live outside the repository. Before you start, check three things: that you have a Kubernetes cluster and Docker available, since everything in the roadmap runs on them, that you are willing to follow one use case rather than jump between topics, since attrition prediction for a large organisation is carried end to end, and that the licensing split does not block you, because the code is Apache 2.0 while the written content is All Rights Reserved. The last push was on 2026-09-15 and there are no GitHub releases. ## FAQ ### Who is the mlops-for-devops course written for? DevOps, platform and SRE engineers, on the argument that most MLOps resources are written for data scientists learning infrastructure. The README says no machine learning background is required and that every concept is explained through DevOps analogies. ### What does the mlops-for-devops course actually build? An employee attrition prediction model for an organisation of roughly 500,000 employees, carried end to end. Phase one covers the dataset pipeline, data preparation, training the model and deploying it as a live API with KServe, and phase two covers versioning, features, orchestration, tracking, deployment and monitoring. ### Which tools does the mlops-for-devops tech stack use? Python and Airflow for data pipelines, scikit-learn for training, FastAPI, Flask, Docker and KServe for serving, Kubeflow and MLflow Pipelines for orchestration, Evidently AI for monitoring, and Kubernetes with Helm for infrastructure. ### Can I use the code and guides from mlops-for-devops commercially? The project is dual licensed. Code, meaning scripts, configs and manifests, is Apache 2.0, while the content, meaning the README, guides and docs, is All Rights Reserved, with a commercial licensing contact listed for the written material. ### Is the capstone MLOps project in the repository? No, it is listed as planned. The README describes a capstone that combines everything into a production-style MLOps platform on Kubernetes, but the code in the repository is organised as phase-1-local-dev, phase-2-enterprise-setup and platform-tools. ## Sources - [Issues](https://github.com/techiescamp/mlops-for-devops/issues) - [Project website](https://devopscube.com/devops-to-mlops/) - [README](https://github.com/techiescamp/mlops-for-devops/blob/main/README.md) - [techiescamp/mlops-for-devops on GitHub](https://github.com/techiescamp/mlops-for-devops) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/techiescamp-mlops-for-devops