CI/CD Best Practices

CI/CD best practices come down to one promise: any commit on main can go to production safely, and quickly enough that nobody is tempted to work around the pipeline. Continuous integration keeps that promise on the code side, by merging small changes often and testing every one. Continuous delivery keeps it on the release side, by making deployment an automated, repeatable, boring event rather than a ceremony.

Most pipelines drift away from that over time. Builds slow down until people batch changes to avoid waiting. Flaky tests teach everyone to click re-run. Workflows collect long-lived cloud keys and third-party actions referenced by tags that anyone with access to that repository can move. Each artifact is rebuilt per environment, so what reached production is not quite what was tested. And releases go to everyone at once, so a bad change is a full outage instead of a small canary.

This guide follows the path of a change. The first chapters cover the integration side (trunk-based development, fast feedback and tests you can trust). The middle chapters cover the pipeline as an attack surface, using the GitHub Actions security guidance as the concrete example, and the build artifacts themselves, using SLSA provenance. The last chapters cover deploying gradually, rolling back fast and measuring how well it all works with DORA's software delivery metrics.

Every practice was checked against primary sources: DORA's research and capability guides, the GitHub Actions security documentation, the SLSA 1.2 specification and the Google SRE workbook. The examples use GitHub Actions because it is widely used, but each practice applies to GitLab CI, Jenkins, Buildkite or any other system.