Continuous integration and delivery

Continuous integration and continuous delivery keep software in a state where it can go live at almost any time, so releasing becomes a routine non-event rather than a big day with its own risk.

Continuous integration

Everyone merges small changes into the main line often, and an automated build and test run proves the whole thing still works each time. Short-lived branches and frequent merges keep integration pain small and constant, instead of large and rare.

Continuous delivery

Every change that passes the pipeline can be released. Deployment is automated and repeatable, so shipping is a decision rather than a scramble. Whether we release on every merge or on a schedule is the client’s call to make.

Habits that keep it trustworthy

• Keep the build fast and green. A permanently red build just trains people to ignore it.
• Automate the boring, error-prone steps rather than writing them down and hoping.
• Test at the right levels so a green pipeline actually means something. See test strategy.
• Run the pipeline on a schedule even when nothing has changed. Dependencies, base images and shared infrastructure move without you, and a nightly run finds out before a Friday deploy does.