JOVANA
Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

From Notebook to Production

A model that wins in a notebook is only a claim; a model millions rely on is a promise. This guide walks the MLOps lifecycle — tracking, the registry, CI/CD, and reproducibility — that turns one into the other.

The gap between a result and a product

By now you can train a model that scores well — a tuned gradient-boosting ensemble or a fine-tuned network that beats your baseline on the test set. In a notebook, that feels like the finish line. It is not. A notebook result is a *claim*: "on this data, with this code, on my machine, last Tuesday, I got 94%." A product is a *promise*: "this service will keep returning good answers, to strangers, every second, for years, as the world changes underneath it." MLOps is the engineering discipline that turns the claim into the promise.

The hard truth is that traditional software engineering only gets you halfway. Code has two moving parts — the code and its inputs. An ML system has *three*: code, data, and the trained parameters that result from running code over data. Any one can change and break the others silently. That third axis is why ML needs its own operational toolkit, and why "it worked in the notebook" is the beginning of the story, not the end.

The lifecycle is a loop, not a line

It is tempting to picture the path as a straight line: gather data, train, deploy, done. Reality is a loop that never quite closes. Data is collected and cleaned; you train and evaluate; a good model is registered and deployed behind a serving layer; then you *monitor* it in the wild — and what you learn from monitoring sends you right back to the data. Each lap should be cheaper and safer than the last. The whole point of MLOps is to make going around that loop boring, instead of a heroic one-off.

Underneath the loop sits the ML pipeline: the chain of steps that takes raw data and produces a trained model. Treating that chain as a real artifact — code you test and run on demand — is the first leap out of notebook culture. The notebook is a *workshop* for discovery; the pipeline is the *factory* that rebuilds the result on command. When teams share a feature store, they go one step further and reuse the exact same engineered features across training and serving, killing a whole class of subtle bugs where the live data is computed differently than the training data was.

Track everything: experiments and the registry

Every practitioner has lived this nightmare: a brilliant result on Tuesday, and by Friday no one — including you — can reproduce it. Too many things changed at once. Experiment tracking is the cure. For every training run, you log the hyperparameters, which dataset and code version it used, the random seed, the environment, and how it scored on each metric. Now "what did I do?" has an answer, and you can compare a hundred runs side by side instead of trusting your memory of three.

Tracking captures *experiments*; the model registry captures *decisions*. Out of a thousand runs, a handful are worth keeping. The registry is the versioned shelf where those candidate models live, each tagged with its lineage (which run, which data, which code) and a stage: staging, production, archived. Promoting a model to "production" becomes an explicit, auditable act — not someone quietly copying a file named model_final_v2_REALLY_final.pkl onto a server at midnight.

run 042  acc=0.94  lr=3e-4  data=v7  code=a1b9c2
run 043  acc=0.95  lr=1e-4  data=v7  code=a1b9c2   <- promote
registry: fraud-classifier  v3  stage=production  from run 043
Tracking compares runs; the registry pins the winning one — with its full lineage — to a named, versioned, promotable slot.

CI/CD for ML: automating the path to ship

In ordinary software, CI/CD means: every code change is automatically tested and, if it passes, automatically released. CI/CD for ML keeps that spirit but widens the trigger and the tests. A change can be new *code*, or new *data*, or a new *model* — and the automated checks include things classic software never worried about: does the model still beat the baseline? Did accuracy on a protected subgroup drop? Is the inference latency within budget? Only if every gate passes does the new version get promoted.

  1. A change lands — new code merged, fresh data arrives, or a retrain is triggered on a schedule.
  2. The pipeline runs automatically: validate the data, rebuild features, train, and evaluate against held-out tests.
  3. Quality gates decide: must beat the baseline, stay within latency and fairness budgets, and pass behavioral checks on known-hard cases.
  4. If it passes, register the new version and roll it out gradually — to 1% of traffic first, watching, before everyone.

That gradual rollout matters more than it might seem. A model can pass every offline test and still misbehave on live traffic, because the real world is never exactly the test set. Shadow deploys (run the new model silently alongside the old, comparing) and canary releases (a tiny slice of real users) catch problems while they are cheap to undo. The instinct to ship to everyone at once is the instinct that causes 3 a.m. rollbacks.

Reproducibility: pin everything, trust nothing

Reproducibility is the quiet foundation under all of this. It means: given the same data, code, and configuration, you get the same model back — bit for bit if you are lucky, behavior for behavior at minimum. That sounds obvious, but it is brutally easy to lose. An unpinned library upgrades and changes a default. A dataset gets quietly re-collected. Someone forgets to set a random seed. None of these throw an error; they just make last month's result unrepeatable, and then you can never tell whether a change *helped* or whether the ground simply shifted.

The fix is unglamorous discipline: version the data, not just the code; pin every dependency to an exact version; record seeds and hardware; and package the environment (often in a container) so it runs the same on a colleague's laptop as on the training cluster. Watch especially for data leakage — when information from the test set sneaks into training and inflates your scores — and for a train/validation/test split that quietly shifts between runs. Reproducibility is not a feature you bolt on at the end; it is a property you protect from the first commit.

Why the loop never closes

Here is the part that separates ML systems from ordinary software, and it is worth being honest about. A correct sorting function stays correct forever. A deployed model slowly *rots* — not because its code changed, but because the world did. Shopping habits shift, slang evolves, fraudsters adapt. This is data and concept drift, and it means a model that was 94% accurate at launch can quietly slide to 80% with nobody touching a line of code. That is why model monitoring is not optional: you watch live inputs and predictions, compare them to training-time distributions, and trigger a retrain — sending you back to the top of the loop — before users feel the decay.

Notice what MLOps is *not*. It does not make a weak model strong, and it does not make a model "intelligent" in any grand sense — these are operational practices, not magic. Nor does pushing a large language model behind an API turn it into an autonomous agent that manages itself; the monitoring, the gates, and the human judgment about when to retrain are all still done by people. The honest framing is humbler and more useful: MLOps is the plumbing and the hygiene that let a *good* model keep being good, safely, for a long time. Get the loop turning smoothly, and the model in your notebook can finally become something millions of people quietly rely on.