This series is about practices we do, without understanding why we do them, and therefore may not get the value we want from them. If you too don't benefit from them, you might be doing it wrong.
Iteration planning, Pt. 1	Iteration planning, Pt. 2	Definition of done	Demo
Done-Done	Daily stand-ups	Retrospectives	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?

They seem to mark the territory of our knowledge. If I think of JUnit as “unit testing”, therefore by using JUnit, I “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 are some bad news.

Jenkins is not CI.
JUnit is 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 incrementaly 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 spanbetween 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 frequent 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 adaptibility.

No tool has those on the box.