Continuous Integration or a build server?

I don’t know if I am walking around the wrong neighborhoods, but few times I heard something like “We are practicing continuous integration with Hudson”.

Maybe it is just me, but that doesn’t look right. Once again we felt in the Tool X Concept trap, Continuous Integration is a concept and Hudson (or any other CI server) is a tool. Let’s start first by the CI server.

A CI server is nothing more than a server responsible to build your stream, it usually (but not always) looks at committed code, once it is committed he start a new build, most like a test suite and other QA tools. But that is all.

In a simplified way of thinking, the CI server just builds (sure that it does more).

But if you look at the definition of Continuous Integration you will see a lot more. I will use the definition provided by Fowler[1], which I think is quite accurate:

Continuous Integration is a software development practice 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. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

Let me highlight the first paragraph, that is the most important “Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day”[1].

As we can see contusion integration is about everyone integrating in the same code base, the benefits come from here. If everyone integrate in the same place, everyone sees the same code and everyone is working in the same base.

Those problems that derivates of late integration, like: merge, code duplication, features overwritten, … are minimized or even extinguished.

And to make it work in a reasonable way an integration server is required, or let’s say desired. But at the same time, if you don’t work with the CI concepts, let’s say you are brave enough to work in Branch Per Feature, for example, you still can profit from a build server BUT you are not doing Continuous Integration.

Ok, ok, so once again you are just talking about definitions! Yes and no. Definition is important because when you are doing CI another challenges show.

For example, if everyone integrates daily I may have a code base with 1/2 feature promoted. And IF I want to use that code base to delivery in production? Should I delay my production deploy? Should I deploy with half feature?

Well there is a lot of way to do that, the best is put effort to fit the features in the deployment cycle, but we all know that one or other feature will not be there; there is some effort put on this question and one of the common accept solution is to use what Fowler calls as FeatureToggle[2], but other names are used like Feature Bits[3].

But I will keep this topic for a next post, so next time that you say CI think: “Do I really use it? Yes? No? If no, do I want? Yes! What do I need to do so?”

Using CI pays the effort, but you will notice that it is a long way to it. So no better sound track for that than AC/DC with It’s a Long Way To The Top.

[1] Fowler, M. Continuous Integration, 2006. http://www.martinfowler.com/articles/continuousIntegration.html

[2] Fowler, M. Feature Toggle, 2010. http://martinfowler.com/bliki/FeatureToggle.html

[3] Sowa, E. Loh R. Feature Bits: Enabling Flow Within and Across Teams. http://www.infoq.com/presentations/Feature-Bits