Are you doing CI or CI Theatre ?

May 27, 2017

There are many Continuous Integrations tools available - Jenkins (the most popular one), and other hosted tools such as Circle CI, Wercker, Codeship, Bitrise to name a few. Does it mean that if we are using any of the tools, we are "doing CI?"

The following is the definition of Continuous Integration as per the Wikipedia:

Continuous Integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.

According to the definition above, if you are not integrating at least once in a day to mainline (aka trunk), then it is not Continuous Integration. Instead, it is called CI Theatre which means:

• Running CI against a shared mainline but with infrequent commits, so integration isn't really continuous;

• Running a build with poor test coverage

• Allowing the build to stay red for long periods;

• Running CI against feature branches which result in continuous isolation

Commits as communication

CI Theatre gives the developers a good feeling, but sadly it misses out the benefits.

Commits are the way to communicate between the developers. If we are delaying that for later by not committing or committing to a branch, then it is a problem as it is important to communicate at the right time.

The Feature Branching popularised by Github Flow makes sense for Open Source where you need a more rigorous way to look at what goes into the codebase, in an organisation where you seem to be knowing or can know each individual who commits code, a very strict commit policy may not be required.

If you believe that your environment totally demands Code Review, do pairing which is the best way to review as it is a continuous review or have short living branches i.e. branches those live for few hours to a day or two.

^{Courtesy: Feature Branching is Evil by Thierry de Pauw}

And the tooling is not important for doing Continuous Integration. Read Continuous Integration a Dollar a Day, to see how to "do CI" with an old machine and a rubber duck.

Once you start doing CI [not CI Theatre], see whether you pass the CI certification test.

If it passes, excellent. You are on the right track for Continuous Delivery.

Wrong branching strategy

I got a chance to listen to Alain Hélaïli about End to End Agility @ Github in which he emphasised that the branches are short lived @ Github than the complex long-lived branches as shown above. And they deploy 50 times a day to production. But it is sad to see that many of us ignore "short-lived" from the branching and say we follow Github flow which kills the purpose.

I also heard about an organisation installing a daemon on every developer machine which deletes uncommitted changes. That will be really fun :)