Project structure · AI and ML
MLOps pipeline project structure
Opens with creditsFor engineers who can train a model and now need the training to be a pipeline anyone can rerun, review and release. A uv workspace holds the pipeline package (prepare, validate, featurize, train, evaluate, register steps run by DVC), a small shared feature package, and a separate FastAPI prediction service that loads models from the MLflow registry by alias. It grows into CI that reproduces the pipeline on pull requests, scheduled retraining, approved promotion and monitoring.
How it grows
Each stage opens the explorer there
- 1Day 1What the scaffold and your first hour give you25 files and folders
- 2GrowingWhat a real app with features and tests adds+54 files and folders
- ProductionWhat running it for real users adds+46 files and foldersOpens with credits
- ExpertWhat a team needs to keep it healthy for years+26 files and foldersOpens with credits
How it is organised
- The pipeline is code: every step is a function with a CLI command, `dvc.yaml` wires the steps together, and `dvc repro` rebuilds data, features, model and metrics from raw data.
- Raw data is never edited. DVC versions it, and every derived file can be deleted and rebuilt.
- Parameters live in params.yaml, read through one typed loader. Changing a value reruns only the steps that use it.
- Feature code lives in one small package used by both training and serving. Two copies of feature logic is the most common reason a model scores well offline and badly in production.
- Every run is tracked in MLflow with the git commit and data version. Serving loads `models:/eta@champion`, so a release or rollback is an alias move, not a rebuild.
- Gates are code: a challenger must beat the champion and the baselines, pass behaviour and slice checks, and match the serving contract. A person approves the final alias move.
- Test four things separately: code (unit), data (schemas), model (quality and behaviour) and the pipeline end to end on a committed sample.
- Training and serving are separate deployables with separate dependencies. The serving image never contains training libraries, data or a model file.
- Add Expert pieces (a feature store, release automation, generated model cards) when several models or teams depend on this repo, not before.
At the top of the project
Open one in the explorer for the full story
- eta-mlops/
- .venv/The workspace virtual environment that uv creates from uv.lock.
- .git/Git history; uv init runs git init for you.
- .gitignoreWritten by uv init for Python caches and .venv; you add data, models, mlflow.db and .env.
- .python-versionThe Python version uv uses for this project.
- README.mdWhat the model predicts, how to set up, how to reproduce the current model.
- pyproject.tomlRoot project: metadata, dependencies, the eta command, workspace members and tool settings.
- uv.lockExact versions for every workspace member, written by uv.
- .envLocal settings and secrets: tracking URI, bucket credentials.
- .env.exampleEvery variable the project reads, with safe placeholder values.
- mlflow.dbThe local MLflow tracking database (SQLite, the default backend since MLflow 3.7).
- mlruns/Local MLflow artifact storage: logged models, plots and files for each run.
- notebooks/Exploration only; anything that matters moves into a step.2 inside
- data/Raw, prepared and feature data. Large files are tracked by DVC, never by Git.6 inside
- src/The src layout uv init creates: importable code lives only here.1 inside
- packages/Small workspace packages shared by the pipeline and the serving service.1 inside
- params.yamlEvery tunable value, grouped by step: split dates, feature options, model parameters, gate margins.
- dvc.yamlThe pipeline: each stage's command, inputs, parameters and outputs.
- dvc.lockThe hashes of every stage's inputs and outputs from the last run.
- .dvc/DVC's folder from `dvc init`: config, its .gitignore and the local cache.4 inside
- .dvcignorePaths DVC skips when scanning the workspace.
- models/The trained model written by the train stage, as a DVC output.
- metrics/Metrics and plot data from the evaluate stage, small enough to commit.3 inside
- tests/Tests for the pipeline: code, data, model behaviour and the pipeline end to end.4 inside
- MakefileShort commands: make setup, test, lint, pipeline, serve, ui.
- .pre-commit-config.yamlHooks on every commit: ruff, nbstripout, large file check, uv lock check.
- docker-compose.ymlA shared MLflow server with PostgreSQL for metadata and MinIO as S3-compatible artifact storage.
- AGENTS.mdInstructions for coding agents: commands, where features live, what never to commit.
Learn more on Sefism
Roadmaps, cheat sheets and projects that go with MLOps pipeline.
- Roadmap· Classic MLMLOps and LLMOps roadmapShip, serve and monitor models
- Roadmap· General machine learningMachine learning roadmapData, models, deep learning
- Roadmap· Towards ML engineeringData science roadmapStatistics, pandas, ML, experiments
- RoadmapDevOps and cloud roadmapLinux, Docker, Kubernetes, AWS
- Cheat sheetMLOps and LLMOps cheat sheetShip, serve and monitor models.
- Cheat sheetMachine learning cheat sheetData, models, deep learning.
- Cheat sheetPandas cheat sheetReading data, selecting, filtering, missing values, groupby, merge and join, reshaping and dates in pandas, with copy-on-write in mind.
- FYP idea· IntermediatePharmacy Demand Forecasting Service with Drift Monitoring and Automated RetrainingA weekly demand forecasting service for small pharmacy chains that is run the way production ML should be: versioned data, tracked experiments, an orchestrated retraining pipeline, a quality gate, drift monitoring and one-step rollback. An intermediate machine learning final year project where the operational loop, not a fancy model, is the contribution.
- FYP idea· BeginnerModel Card and Datasheet Generator from Training RunsModel cards and dataset datasheets are the standard way to document what a model does, what data it learned from and where it fails, but they are written by hand at the end, if at all. Build a generator that pulls facts from MLflow runs, dataset files and evaluation results, drafts a model card and datasheet, flags missing or unsupported sections, and keeps the card in sync as the model is retrained.
See 9 moreShow fewer
- FYP idea· AdvancedFine-Tuned Small Open Model with Eval-Gated Releases and Self-Hosted ServingA pipeline for startups and support teams that pay per token for one narrow, repetitive LLM task: fine-tune a small open model with LoRA, release it only when it passes an eval gate against the hosted API baseline, serve it with vLLM behind an OpenAI-compatible endpoint, trace every request and report quality, latency and cost. An advanced AI final year project that turns an API bill into an engineering decision.
- QuestionHow do I become an MLOps engineer?MLOps engineers keep models working in production: packaging, versioning, pipelines, serving, CI/CD and monitoring. Come in from either software or DevOps with ML basics, or from ML with engineering habits. Learn the lifecycle in order, then prove it with one model you deploy, monitor and roll back yourself.
- QuestionWhat is the difference between a data analyst, a data scientist and a machine learning engineer?Analysts answer business questions with SQL, spreadsheets, dashboards and reports. Data scientists add statistics, experiments and predictive models. ML engineers build and run models inside production software. Titles vary by company, so read the work in the job advert, and pick by the kind of problem you enjoy, not the title that sounds most senior.
- QuestionMy machine learning projects never leave a Jupyter notebook. How do I learn to deploy a model?Move the notebook code into a small Python package, save the whole preprocessing and model pipeline, put it behind a FastAPI endpoint in a Docker container and deploy it. Then add what makes it production: tracked runs, a registry, a test in CI, prediction logging and a drift check. Start with batch predictions if you can.
- Resource· ToolDVC DocumentationThe official docs for DVC (Data Version Control), the open source tool that versions large datasets and model files next to Git and turns training steps into reproducible pipelines. It is the simplest way to answer "which data trained this model?" and to rebuild any past model with one command.
- Resource· Tooluv DocumentationThe official docs for uv, the fast Python package and project manager from Astral. It replaces pip, virtualenv, pip-tools and pyenv for most projects, and its lockfile is what makes an ML project install the same way on your laptop, in CI and in a Docker image. Free, open source and quick to learn.
- Resource· ToolEvidently DocumentationThe official docs for Evidently, an open source Python library for evaluating, testing and monitoring ML and LLM systems. Its drift reports and pass or fail tests are one of the quickest ways to add real model monitoring to a project, with a self-hosted dashboard when you need one.
- Resource· GuideMLOps: Continuous Delivery and Automation Pipelines in Machine LearningGoogle Cloud's widely cited architecture guide that defines MLOps maturity levels 0, 1 and 2 and explains continuous training alongside CI and CD. Free, short and tool-neutral in its ideas, it gives a team a shared picture of where it is and what to automate next.
- Resource· GitHub repoMachine Learning Engineering Open BookStas Bekman's free, open book on the engineering side of training and serving large models: accelerators, memory, networking, storage, orchestration, debugging and inference. Written from hands-on experience, including leading the BLOOM-176B training, it is the reference to reach for when your models meet real GPUs.
Checked against 11 official sources, October 2026. If something has changed, the docs win.Show sourcesHide sources
Best practices and checklists for this stack
Picked from the other libraries by shared topics.
Best practices
See all- Machine Learning Best PracticesHow to build and evaluate an ML model you can trust: problem framing and baselines, leak-free splits, features, tuning, metrics and error analysis, reproducibility and fairness checks.
- CI/CD Best PracticesBuild pipelines that are fast, trustworthy and safe to deploy from: trunk-based flow, fast tests, locked-down workflows, signed artifacts, canaries and DORA metrics.
Checklists
See all- ML Model Deployment ChecklistAn ML model deployment checklist: baselines, training and serving consistency, validation, model registry, canary rollout, rollback, drift monitoring and ownership, with how to verify each.
- Data Quality ChecklistA data quality checklist for warehouse tables: ownership, freshness, volume, schema, nulls, uniqueness, referential checks, anomaly monitoring and data incidents, with how to verify each.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com