Continuous deployment
Automatically releasing every change that passes the pipeline, with no person pressing a production release button.
What it is
Continuous deployment takes every change that clears the automated pipeline and releases it to production without waiting for a person to approve the release. Merge a small change, the checks pass, and that exact build becomes live. The word deployment is the important difference from continuous delivery, where a validated build can still wait for a human release decision.
Reach for it when changes are small, tests are trusted, production is observable, and the team can roll back quickly. It shortens the time between writing a fix and learning how it behaves under real traffic, without collecting a risky batch of changes for release day. John Allspaw and Paul Hammond's 2009 Velocity talk '10+ Deploys Per Day' about Flickr is still the reference point teams argue from.
Gotcha: automation makes a bad release fast too. A green unit test suite does not catch a broken secret, a destructive migration, or a third-party outage. Post-deploy checks, gradual exposure, automated rollback, and backward-compatible database changes are what make continuous deployment survivable.
Ask AI for it
Set up continuous deployment with GitHub Actions. Trigger on every push to main, run lint, typecheck, tests, and a production build as required jobs, then deploy the immutable commit-SHA artifact to production with no manual approval. Read credentials from GitHub Environment secrets, use concurrency to cancel a stale run before deployment begins, run homepage, health endpoint, and critical-flow smoke tests after the release, and automatically promote the previous known-good artifact if any post-deploy check fails.