Continuous Delivery and Deployment

Continuous delivery keeps software in a tested, deployable state so it can be released when the organization chooses. Continuous deployment also automates production deployment for changes that satisfy the defined conditions. Both depend on a reliable path from change to verified artifact.

Ready to deploy versus already deployed

Imagine a tested assistant release waiting for an operator's production approval. That can be continuous delivery. If the pipeline performs the production rollout automatically after all required checks pass, it follows continuous deployment for that path.

The abbreviation CD is used for both, so spell out the intended meaning. Neither means that every proposed change bypasses evaluation or that users must immediately see every deployed feature.

Preserve the evidence through the pipeline

A release should identify the application code, model reference, prompt, and other compatible dependencies. If production receives a different artifact from the one evaluated, the earlier test result no longer directly describes the deployed candidate.

Define how failed checks stop progression, how limited exposure is observed, and how recovery is initiated. Continuous training is a separate practice that automates a training path; a newly trained model still needs the relevant release checks before deployment.

Reference: Martin Fowler: Continuous Delivery.


Discover more from Insightful Data Lab

Subscribe to get the latest posts sent to your email.

Similar Posts

Questions, corrections, or additional insights?

This site uses Akismet to reduce spam. Learn how your comment data is processed.