I’m just doing some formal training in Agile at the moment and one question I have is about the value of continuous builds vs value of committing to the version control system often.
My understanding with version control is that its better to commit often, because then you have history and the ability to go back to previous changes in a fine grained way.
My understanding with Agile and continuous build is that its there to put pressure on the developers to always have working code. That to break the source tree is a taboo thing to do.
Now I agree with both of these sentiments, but it occurs to be that sometimes these might be working against each other. You may be in the middle of a largish code change and want to commit code to make sure you have history, but this will break the source tree.
Anybody got any thoughts on this?
What could be less Agile than a taboo about something ever going wrong? I would argue that the taboo is to leave the build broken rather than to break the build at all. The occasional build breakage is ok. This is exactly why you are running continuous builds and tests. The CI build/test identifies when the build is broken, and ideally who broke it. This ensures that it’s fixed quickly. If this happens occasionally, you’re ok. If it happens twenty times a day, the team is probably in trouble.
The taboo is to interfere with other people getting their work done. When you break the build, they get an email saying, “our branch of source is busted”. They won’t be able to integrate other people’s changes, or their changes with the mainline until they get the all clear email.
The real challenge in working in this sort of continuously integrating environments are:
1) Keeping the teams pretty small. Generally we start seeing trouble after about 25 developers are on the team. Things start getting fragile. Using team level branches, components or multi-stage CI with streams can help larger teams break into smaller teams.
2) Choosing small units of work. There generally shouldn’t be a conflict between checking in improvements regularly and not breaking everything. Commits should be done when small, working changes are made. The new feature might not be exposed to the user yet, but if a coherent API change is made that doesn’t break tests, check in.
3) Fast, accurate Builds. There are a lot of race conditions that the team tends to win more often when the build gets faster. Plus reproducible builds will ensure that the build the developer does on her own machine (which she had time to do because it was fast) reasonably accurately predicts success on commit.