You're Doing it Wrong: Continuous Integration

When I ask teams “Do you do continuous integration?”, eight out of ten times I get, “We have Jenkins,” or a similar tool. The other two don’t know what I’m talking about.

Jenkins to CI is like JUnit to unit testing (which is, of course, the answer I get when I ask about unit testing). It’s comparing a tool to a methodology (some would say mindset), which is doing it wrong.

We Do Love Our Tools, Don’t We?

The tools we use seem to mark the territory of our knowledge. If I think of JUnit as “unit testing,” by using JUnit, I, therefore, “know” unit testing. Tools are easier to master since they require finite knowledge needed for “mastery.”

We also draw lines between tools and efficiency, since they help us automate tasks. We want to master them to be more powerful. and when we do, we become the resident “tool master.” Feels good, doesn’t it?

So here is some bad news:

• Jenkins is not CI.

• JUnit is not unit testing.

• Jira is not user story management.

CI does not require tools, as James Shore described in “Continuous integration on a dollar a day.” CI is a way to develop software where we, wait for it, integrate continuously. We add pieces of functionality to the existing code base and don’t break it.

In fact, we know it doesn’t break, because we have tests that prove it still works. Those feedback cycles support the process of incrementally moving the code forward. It is not possible to continuously integrate without them, because of the fear we might break something.

But Wait, There’s More!

In order to continuously integrate, we need to commit these pieces of code frequently.

What happens if we don’t? Let’s say I work on a branch off the trunk for two weeks. First, if I don’t merge changes others have committed, I will have a big juicy, risky, frightening merge to go through before I commit. Then, the others won’t get my changes as well. The bigger the time span between merges, the more risks (and therefore delays) we add.

If however, we do very small merges, like every a couple of hours, the merges are small, and others get to enjoy my contributions early.

Much like unit testing, the more frequently we do it, we’re encouraged to do it more. The less we do it, we’re encouraged to delay the big merge.

This doesn’t happen because of a tool. A tool won’t make you commit small changes or write more tests. The tools are enablers, and it’s a choice to use them for their benefits.

A brain - and if possible, a collection of brains - is required to continue, trip over problems, fix them and continuously optimize. CI requires discipline, effort, and adaptability.

No tool has those on the box.