Six Aspects for Self‑Assessing Continuous Integration Maturity

The following excerpt is taken from the author’s new book Continuous Delivery 2.0 , Chapter 9, and introduces continuous integration (CI) as a historically challenging practice that originated from extreme programming and the 1980s “daily build” approach, first documented in Microsoft software‑development management papers.

If readers want to know whether their team has achieved an optimal CI state, they can perform a self‑assessment using the six aspects described below.

1. Trunk‑based development and frequent commits All team members work on the main branch (or keep short‑lived branches no longer than three days) and each person commits at least once per day, preferably every few hours.

2. Each commit represents a complete task Commits should be meaningful, containing code related to a single work item together with its automated test code, rather than being made merely to satisfy a frequency metric.

3. Build verification completes within ten minutes Short build times are crucial because developers have little patience to wait; especially in synchronous workflows, long verification delays slow feedback and increase the cost of investigating failed builds.

4. Block new commits after a failed build When a commit causes a build failure, the whole team should stop submitting new changes until the issue is resolved, following the Toyota Production System’s “Stop the Line” principle to prevent cascading problems.

5. Fix a failed build within ten minutes or roll back If the problem cannot be resolved within the agreed time (e.g., ten minutes), the team should roll back the code to keep the pipeline flowing; prolonged blockage hampers progress and can increase integration risk.

6. Confidence after successful automated verification The true goal of CI is rapid, reliable quality feedback: a passing automated build gives the team confidence in software quality. However, confidence is misplaced if the test suite is thin or if failing tests are simply deleted.

Figure 9‑3: System‑thinking diagram of repair time