A rollback restores yesterday's model weights behind today's incompatible serving code. Another release leaves the preprocessing behind. Preventing these failures means treating model deployment as a versioned change: record the trained artifacts, transformations, configuration and runtime together, then test the package that production will run. Start by mapping that path into the application's release process. Extend familiar CI practices to data and evaluation reports, then distinguish releasing a pipeline from releasing the model it produces. Packaging and environment promotion make the release concrete. Shadow traffic provides evidence before predictions affect customers, and explicit deployment contracts decide what may advance. Finish by keeping the release path exercised between launches. These 2020-2022 accounts explain delivery decisions; their historical tool demonstrations are examples, not current setup instructions.
Why first: Ray puts the model inside the application's delivery process. A commit may trigger training, registration and scoring before an accepted result moves to deployment. Mapping those steps first makes it easier to decide what the existing CI system can support and where manual decisions remain.
Why second: O'Brien extends the familiar Git workflow to the inputs and evidence that ML changes require. Dataset changes must be visible to CI, and reviewers need plots and metrics alongside a pass or fail. Her 2020 examples explain what to attach to a proposed release before automating the rest of its journey.
Why here: The artifact being delivered is not always the trained model. Hershey separates building pipeline components, deploying the pipeline, running it and publishing its model output. That distinction prevents one successful job from standing in for the whole release, and makes the required records easier to specify.
Why here: Marsden asks exactly what the release contains. His preference for baking weights into a serving image makes the model and runtime one versioned unit; downloading weights instead leaves two versions and a startup dependency to track. This is the packaging decision to settle before promoting anything between environments.
Why here: Prathish adds the transformations that a model file can leave behind. Innovyze recorded cleaning and feature engineering as configuration and used a shared path from development through QA to production for customer-specific models. Packaging is only useful when the promoted result still receives the inputs it was built for.
Why here: Haaga makes promotion a recorded change. Interos checked the expected project structure automatically, then changed image tags and model-weight paths in versioned environment repositories. The release can be reviewed as a specific change instead of reconstructed from someone remembering which commands they ran.
Why here: Lathia separates running a new model from acting on its predictions. Monzo's shadow mode logs real requests and outputs while customers remain on the existing behavior. Its different validation requirements for different risks give promotion a decision point beyond whether the deployment completed.
Why last: Stripe turned business expectations into release contracts, then kept data generation, training and evaluation running even without a planned launch. Ameisen's warning is practical: a delivery path that sits unused decays. Automation earns trust by repeatedly exercising the route you will need for the next release.