Continuous Integration is Not a Tooling Problem

Written by , in category Software Craftsmanship

31 March 2020

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 ...

So excited to announce that GitHub now includes built-in CI/CD!

-- @natfriedman, Twitter

My friend Steve Smith debunked that immediately. I didn't expect less from Steve.

No. A tool cannot "include built-in CI and CD"
- #ContinuousIntegration is a practice
- #ContinuousDelivery is a set of principles and practices
A tool can do build and deployment actions well, but it can't do more than that. You'd hope the GitHub CEO would know better #ohdear

-- @SteveSmithCD, Twitter

Despite the efforts of the XP community, people still believe a tool can build Continuous Integration into a team.

This seems a niche hill on which to battle, but I'll bite. 🙂
Disagree. CI and CD are practices codified, automated, and automatic. Else they are not continuous, nor integrative, nor do they deploy reliably in any way.
Lacking tooling, CI/CD are academic at best, yea?

-- @Strofcon, Twitter

What is Continuous Integration

Continuous Integration is a software development practise where members of a team integrate their work frequently, usually, each person integrates at least daily -- leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

-- Martin Fowler, Continuous Integration

It is a practice designed to ensure that your software is always working, and that you get comprehensive feedback in a few minutes as to whether any given change to your system has broken it.

-- 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:

  1. Does everyone in the team push their code into a shared mainline (not branches) on a daily basis?
  2. Does every commit trigger an automated build and execution of all unit tests?
  3. 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:

  1. 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.
  2. 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.
  3. All engineers push their code at least once a day (preferably multiple times a day) to a shared mainline.
  4. Integration builds occur several times a day on a separate build server.
  5. 100% of the tests must pass for every build.
  6. 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.
  7. 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:

  1. first of all, a centralised version control system;
  2. 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.

Conclusion

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.

Acknowledgement

Thanks to Steve Smith for reviewing this article.

Bibliography

  1. Continuous Integration, Martin Fowler
  2. Continuous Integration, Jez Humble
  3. On DVCS, Continuous Integration and Feature Branches, Jez Humble
  4. The Continuous Integration book, Paul Duval

This article was first published on the site of ThinkingLabs the 23th of March 2020.
The original article can be found here.

1 Comment

Comments are closed.


The reCAPTCHA verification period has expired. Please reload the page.

Categories

-->

Never miss an article again!

Relevant information about Agile and scrum by the best
Updates on our amazing public events
Max 2 times per month