The Six‑Step Commit Method for Effective Continuous Integration

Continuing from a previous case study, the article highlights the need for low‑cost, early detection of code problems as development teams increase integration frequency.

It clarifies that many teams misunderstand Continuous Integration (CI) as merely clicking a Jenkins build button, whereas CI is a daily collaborative practice defined by Martin Fowler: developers frequently integrate their work, each integration is automatically built and tested to catch errors early.

The core of the article presents the "Six‑Step Commit Method" (also called the "check‑in‑dance") used to enforce disciplined CI:

Update the workspace with the latest passing build from the CI server.

Modify product code and add or update related test code.

Run the automated test suite locally and ensure it passes.

Verify the latest successful build on the main branch, merge it with local changes, and run the tests again.

Commit the local changes to the main branch.

The CI server detects the change, performs an automated build and test run, and only after success releases a token that allows the next commit; if the build fails, the author must fix it before anyone else can commit.

The article then answers nine frequent questions about the workflow, explaining why steps 3 and 4 require two test runs, how to handle concurrent commits, the trade‑offs of batch submissions, and how to keep test execution time short (ideally under 10‑15 minutes).

It suggests practical enforcement mechanisms such as a unique token for committing and visual CI status indicators (e.g., a "luma lamp" that turns red, yellow, or green based on CI health), as well as assigning a temporary "CI police" to remind the team of the discipline.

Finally, the article notes that additional challenges like test strategy and build‑time optimization will be covered in a future post.