How it works
Continuous integration means developers merge their work into a shared branch often, and each change is built and tested automatically. Continuous delivery means every change that passes is ready to release at the push of a button. Continuous deployment goes one step further and releases it automatically. Together the steps form a pipeline, which typically looks like this:
- A developer pushes a change to a repository such as GitHub.
- The pipeline installs dependencies, checks style and runs automated tests.
- It scans dependencies for known vulnerabilities and checks for leaked secrets.
- It builds the app and deploys it to a preview or staging environment.
- After review, it releases to production, with a way to roll back.
Why it matters
Small, automatic releases catch mistakes sooner and make each one easier to trace. The pipeline is also where security checks run on every change instead of once before launch, which fits the habit of testing before every release. Pair it with a secure code review, because automation finds known patterns, not design flaws. Our secure-by-default checklist shows what to automate first.
An example
Imagine a team that ships a web app on Vercel from a GitHub repository. Every pull request gets a preview link and a test run, and merging to the main branch deploys it. If a release causes a problem, the team rolls back to the previous version. This is a hypothetical example, not our work.
Common mistakes
- Ignoring flaky tests until nobody trusts the pipeline.
- Storing secrets in the repository instead of the pipeline's secret store.
- Giving pipeline tokens more access than they need.
- Having no rollback plan.