2008-09-18

Continous Intergration - continous headache?

Recently attended a seminar, a free seminar, on Continuous Integration, or CI for short. It was Informator hosting it and two guys from Objektfabriken who held the actual seminar.

There are a number of good tools to get CI rolling. But is it as easy everybody claims? Tools are good, bu you need a process too and, even more crucial, backing from management. Without it, nothing can really be done in the area of CI. I.e. introducing CI requires such a level of effort (LOE) that you cannot hide it for long before it shows in your time reports, etc.

What is this thing with LOE and CI and process?? Well, you cannot just hook up CruiseControl to your Subversion repository and think you're up and running. There are a number of other aspects to consider; to what degree will engage others in your team? What branching strategy are in use at your organization? Will the introduction of CI imply changes in your organization? ... and are those in this organization ready for a change? Will this change be introduced gradually or are you planning to do it "Big Bang" style? There are of course numerous questions that needs to be addressed before you can start doing the practical stuff. Please keep in mind; every project and organization is unique in their own respects.

Degree of CI: there is a continuous scale, it basically describes the degree of isolation between development efforts. I.e. how much a change affects others in the team. In one end there is basically no isolation - this implies basically no branching strategy and thus a change can affect everybody in the organization. You have developers check-in their changes directly to the main branch in you source repository.

In the other end of the spectrum, you enforce a strict branching strategy where people have to take in updates on isolated branches, run test cases, before checking in their changes. Then merge in their change to the main branch. The latter will not render any problem as the issues involved with merging has already been dealt with in the isolated branch. The very end of this range of CI is reached in the latter if developers are continuously updating their isolated branch with any change introduced in the main source branch.

So, you can probably also see that there is also a degree of effort, cost, required; low effort - low safety or higher risk, high effort - higher safety and lower risk.

What to do now? You have to decide where on the scale to start. Do you want start in one end and move towards the other? Or, do your organization require a certain level and stay there? I think it is all up to what you want to achieve and how much risk you are prepared to take.

And... please keep in mind: Developing software is a people thing.

1 comment:

TeNGiL said...

Indeed an interresting topic. I dare to say that I agree with you. It's a big cost that might not return its investments after all...

While we are at it, a survey on Agile and CI:

http://www.theregister.co.uk/2008/10/10/aligndev_workshop_roundup3/

Keep up the good work, Robert!