Continuous integration x Versionless software

10 days ago I got the “ThoughtWorks Anthology” book and was amazed by how some of our ideas matched what was implemented in their projects/clients – in a broader scale, of course. The thing that amazed the most was one of the most difficult steps, that we face since we were little kids with our first home-made software.

Everyone has already said and heard once in their life the nasty comment: “it works in my machine”. Unfortunately it does not matter if your client is your friend, your teacher, or your client – a software is only functional when its working at the client’s machine.

The last mile

In the anthology book, TWers mention what they call the last mile, the requirements to make it possible and easy to deploy large software in production more frequently. Blindly-adopting agile techniques from XP and Scrum is not enough.

Its necessary to notice how important it is to automate the entire deployment cycle. This is not an easy task – it takes a lot of effort to reproduce your client’s production configuration: machines and data. Going even further, your deployment scripts need to automatically clone that configuration every time one needs to run regression tests.

Right now, just a few of our projects are one-click away of going into staging and production, but the advantages of such approach are quite clear by now. I just want to mention the one that the Anthology book mentions but does not give a solution: producing versionless software that can be deployed at any time.

The problem: working in more that one history at the same time

In larger projects – or continuous projects – there are more than one team working or more features being developed at the same time. Although this can be controlled using some practices in the books, the most common problem is still keeping the trunk one-click-deployable at any point in time while the branches might not be in such condition.

3 teams : 1 project

Imagine the situation where there are two teams working on new functionalities and one fixing bugs. Those teams might be as small as two-persons pair programming.

In this scenario, all teams work in local branches of the project (using git) and push them to the remote server whenever they think its time to integrate with the trunk (master). Our continous integration tool can be configured in such a way that it detects new branches and run the build process for those branches too. As soon as the build is finished, only the commiter team receives the result (which could be implemented through email or CC menu). Its job will not affect other teams while they can not integrate with the trunk.

At the same time, the other two teams also commit to remote branches which, in turn, returns the result to the ones responsible for the code. Trunk integration is only made when their code can be safely integrated.

This approach is basically the same idea from “integrating your code to the server occurs only when the unit tests are green”, but changing a little bit in order to become: “integrating your code to the trunk/master occurs only when all tests are green”.

If a team merges its branch to the trunk/master, its effects will soon be pull’ed by the other teams.

This is not pure continuous integration as code from all teams are not integrated every commit within theirselves, but their code is integrated whenever they rest assure that theirs commit side-effects have been minimized.

Such solution allows us to keep a trunk/master one-click deployable all the time so bug fixes and new features can be delivered as soon as they are finished, without the need for the entire release-cycle to be over.

But why would I need to deploy so often?

At Agile Brazil 2009, i’ve become aware of the problem that our most long running project faces. A 1 week iteration and 2 weeks release cycle is really fast in a developer’s point of view. For a company which keeps doubling in size every year, their software must keep up the pace and be able completely change implemented processes a number of times a year.

Its processes evolves and changes completely over the course of the year, because half of the existing processes  within the company are not even one year old.

2 week release cycles allows us to give the client 24 opportunities for innovation/change over an year. This does not mean that they have only 24 possible new features, but a new feature will be used and redesigned during the entire year, and 24 possibilities of requirements-awareness (when the built is deployed) is clearly not enough in this case.

Any suggestions on how to give your client even more chances to improve functionalities?