What is Continuous Integration about … and what is not…

It happened to me several times to participate in discussions regarding the implementation of the Continuous Integration [CI] practice. This is typically a task that sooner or later will be addressed by teams and organizations that are making their first steps in the world of agile software development. That are or are not aware of it.

Being able to do CI is itself a symptom and cause of being agile, at least at the level of software production. It may not be enough and anyone who has experienced a period of transition in which the development team has tried to adopt lightweight and more efficient processes, or just more customer-oriented, sooner or later he realized that a certain way of thinking and working should be extended to other departments. Indeed, it must be extended if you want to achieve sustainable development through agile methods and get all the competitive advantages that this entails, before they are basic standards that every software company will have to keep in mind.

Despite CI enables advanced processes such as Continuous Delivery and Continuous Deployment and hides many concepts such as incremental design and, usually, test-driven development, this practice is rather trivial. To emphasize this aspect here are some definitions that major sites give about:

CI is the practice in software engineering, developer of merging all working copies with a shared mainline several times a day [Wikipedia]

Let’s also see the sites where Extreme Programming was discussed at the time of its origins:

Each time your code improves, You Should send each refactor & Additions that improved it to all your colleagues’ computers. These refactors Should overlay their tails, transparently, as they type. The most granular unit of integration Should Be one step of one refactor. All remaining CI research Represents upgrading our only primitive tools to Achieve this. [C2]

Developers Should Be integrating and commiting code into the code repository every few hours, when ever possible.[extremeprogramming.org]

The final part of the C2’s definition seems that there is an obvious addition. Actually Continuous Integration defines a practice that has to do with the pace of committment and with the quality of the software committed, rather than the way this is done. It is to be imply that there is a centralized system of software versioning. The rest are just upgrades. Thinking of setting up a system for automating the build process because it will allow me to make Continuous Delivery without having first treated the way we work in a regime of continuous integration , is like thinking of buying a Ferrari engine without a frame where we can mount the engine. I Can turn it on, make a some tasty smoke and a nice noise, but it will get you nowhere.

Yet this is the kind of issues debated in the tipical discussion about CI I said above. I’ve been there myself. Those were the days of CVS , Cruise Control, Ant and Fitnesse. Even if today we have Git, Jenkins, Casper, sometimes we lack the same basic ingredients:

  • the iron will to give to the customer and / or user even small increase in value as soon as possible, in order to receive feedback as soon as possible
  • the ability to build the software for subsequent increases in value, not for simple addition of lines of code
  • the discipline to produce, as a whole with production code, a fair test network to continuously add value with the maximum degree of confidence
  • the belief that this way of software development will help us work with serenity, even during extreme urgency moments, when the reaction time can make a difference

Features that should be added to the more technical qualities guessed that software developers must possess, along with the soft skills necessary to play any team activities.

So my suggestion is: if you are about to adopt Continuous Integration, probably because you are interested to Continuous Delivery / Deployment, start looking at your teams and follow the beat. Maybe they are already continuously integrating their code and someone else is just following another rhythm. If you notice they are not committing many times a day, don’t waste your time in setting up a CI server but start with a team trying to manually have a build ready many times a day. Work side by side with a couple of developers with the goal to be continuously synchronized. This is just the first step of a long but wonderful journey.