There is this commonly accepted, hard-grained belief in the software industry. By dropping a build server in a team, they get Continuous Integration magically for free. This belief is further incentivised by the marketing of build server vendors.
Back in August 2019, Nat Friedman, CEO of GitHub, announced …
My friend Steve Smith debunked that immediately. I didn’t expect less from Steve.
Despite the efforts of the XP community, people still believe a tool can build Continuous Integration into a team.
What is Continuous Integration
— Martin Fowler, Continuous Integration
— Jez Humble, On DVCS, continuous integration, and feature branches
What does this mean
Jez Humble, co-author of the Continuous Delivery book, has a simple test to determine if a team practices Continuous Integration:
- Does everyone in the team push their code into a shared mainline (not branches) on a daily basis?
- Does every commit trigger an automated build and execution of all unit tests?
- When the build is broken, is it typically fixed within 10 minutes?
Only if you answer yes to all three questions, you are practising Continuous Integration.
This involves adopting the following practices:
- All engineers run a private build on their own workstation before committing and pushing their code to a shared mainline. This to ensure their changes don’t break the integration build.
- The build is automated. Any new team member must be able to check out the code from version control. And execute one command to build the codebase and run all tests.
- All engineers push their code at least once a day (preferably multiple times a day) to a shared mainline.
- Integration builds occur several times a day on a separate build server.
- 100% of the tests must pass for every build.
- A product (i.e. a release candidate binary) is generated that can be deployed in a test environment to undergo acceptance tests.Fixing broken builds is the highest priority.
- Keep the builds (including running unit tests) fast to provide rapid feedback. The XP guideline is less than 10 min. Dave Farley, co-author of the Continuous Delivery book, and myself aim for less than 5 min.
Can a tool build this in
Will a tool ensure everyone in the team runs the build locally before pushing?
Will a tool ensure everyone in the team pushes at least once a day?
Will a tool ensure 100% of the tests are green?
Will a tool ensure a product is created that can be deployed at the end of the integration?
Will a tool ensure a broken build gets fixed within 10 min?
Will a tool ensure the build is fast to provide fast feedback?
Obviously, the answer is no to all these questions.
Does it mean you don’t need tooling to practice Continuous Integration?
Well, to be fair, you do need some basic tooling:
- first of all, a centralised version control system;
- and something that enables you to run a build and execute all unit tests locally using one command-line command, like make, rake, npm, ant, buildr, gradle (maven if you absolutely want to), lein, … and many others.
And that is it. Nothing more, nothing less.
A team needs to adopt all of the above-mentioned practices to pass Jez’s Continuous Integration test and get into a state of Continuous Integration. A tool won’t enable this.
It is perfectly possible to practice Continuous Integration without using a build server (aka “CI-tool”). Conversely, using a build server is no guarantee to practise Continuous Integration.
Thanks to Steve Smith for reviewing this article.
- Continuous Integration, Martin Fowler
- Continuous Integration, Jez Humble
- On DVCS, Continuous Integration and Feature Branches, Jez Humble
- The Continuous Integration book, Paul Duval
by Thierry de Pauw