tezvyn:

Continuous Delivery: Ship Reliably, Anytime

AI-drafted, machine-checkedSource: Wikipedia: Continuous deliveryintermediate

Continuous Delivery (CD) makes software releases a boring, routine event. Your codebase is always in a deployable state, allowing you to ship small, incremental updates reliably and at any time. The footgun is confusing it with Continuous Deployment.

WHY IT EXISTS Traditional software releases were often large, infrequent, and risky events that required significant coordination and downtime. Continuous Delivery was created to solve this by making releases a low-risk, frequent, and predictable activity, reducing the cost, time, and stress of shipping software.

THE MENTAL MODEL Think of your main codebase as always being in a releasable state. The goal of Continuous Delivery is to make deployments a boring, routine business decision, not a frantic, all-hands technical scramble. The software is always ready to go; you just have to decide when.

HOW IT WORKS CD is achieved by producing software in short cycles. Every code change is automatically built and subjected to a rigorous, automated testing process. If all tests pass, the build is considered a release candidate, ready for deployment. This entire workflow relies on a straightforward and repeatable deployment process, often called a deployment pipeline, to ensure consistency and reliability.

WHEN TO USE IT Use CD when you want to increase the speed and frequency of your releases while lowering the risk of each one. It's ideal for teams that need to deliver incremental updates to applications in production quickly, allowing for faster feedback loops and more responsive development.

WHEN NOT TO USE IT CD is not a fit for teams without a reliable, repeatable deployment process or a strong culture of automated testing. Attempting to implement CD with a manual, error-prone release process will only amplify existing problems and lead to unreliable, failed deployments.

ONE CANONICAL EXAMPLE A web development team practices CD. When a developer merges a change, a pipeline automatically builds the software, runs unit and integration tests, and packages it. The resulting artifact is deployed to a staging environment for final automated checks. If everything passes, it's marked as a release candidate. The product manager can then, at any time, click a button to deploy that exact, pre-vetted version to production.

Read the original → en.wikipedia.org

Get five bites like this every day.

Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.