I CI What You Did There!

Whenever I ask people (and I really don’t get tired of asking), what is CI, or Continuous Integration, I get Jenkins. Or TFS. Or another tool.

And this is a teachable moment!

CI is not a tool. These tools are great, don’t get me wrong, but listen to the words. Continuous Integration is a process. It’s doing integration continuously.

CI is the process of working with one main branch. Every bit of code is continuously integrated into that branch. And that main branch is always potentially releasable.

That means a couple of things. First, no side branches. Or more precisely, no long-living side branches. You can’t keep pushing code into your own branch for a few weeks. Not even for days.

Because when you do that, it would eventually be a very painful merge. When the build breaks, because of pushing your painfully merged code – you block everyone else. We’d rather have smaller. easily merged commits.

CI also means that you have enough automated tests running on the main branch to warrant a release. And that means you need to define what is “releasable” for you.

What do you need to have a working CI process?

Easy. Smaller commits.

Ok, smaller tested commits. If I add a bit of code and a test, I deliver tested code into a releasable build.

If I merge my commits a few times a day, the chance of breaking the build is small, as I merge and push less code. Plus, it mostly means automatic merges. Smaller commits mean the chance of somebody else working on the same code at the same time is slim.

And if by any chance, you and I are working on the same code, we both have an incentive to commit first. Because, if I get there first, then YOU will need to do the manual merge. This organic “competition”, leads to smaller code commits too. Of course, if we both working on the same code separately, that’s a whole set of other problems to solve.

When everyone works like that, we always have a potentially releasable product, and we spend less times on merges. That’s a win-win situation.

Tools like TFS and Jenkins help to support that. They are good engines for building, reporting and deploying. But all you really need for CI, is a source control system, and some discipline.

Ok, a lot of discipline.

I talk about CI a LOT in my “API Automation Testing For Developers” workshop, so check it out.