Source control management has always been one of those sticky topics which always causes many questions. Many veteran programmers are baffled by the in-and-outs of branching and merging. And for good reason; it is a difficult topic.
I’ve been around in many different organizations. I’ve been the person who was told what the SCM strategy was, and I have been the person who designed it. I’ve seen it done just about every way possible, and after all that, do you know what I think? (I’ll give you a hint, it’s the name of this blog)
Keep it simple. Working directly off the trunk is by far the best approach in my opinion.
It almost sounds like heresy when I actually type it onto my screen, but if you’ll bear with me for a moment, not only will I show you why I think this is essential for an Agile process, but I’ll show you how to make it work.
Continuous integration is the root
If I had to base my reasoning on one solid argument, it would be the value of continuous integration. I blogged about the value of CI and best practices in the past. I am a pretty big advocate of CI.
As a software development community as a whole, I think most of us can agree that CI is good and provides real value.
What is Continuous Integration then?
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.
Martin Fowler
So the idea here is to integrate as soon as possible, the faster the better. If something is going to break, we want it to break sooner rather than later.
The best way for this to happen is that whenever I check in my code it is instantly integrated with everyone else’s code and we build and test it.
This is a change from the old way of doing things, in which I am working on my code in isolation for some period of time and periodically I show up with a bunch of code and merge it all together.
The only practical way to have continuous integration is to have everyone working off the same branch. It doesn’t have to be trunk, but it has to be the same branch. Sure, there are some ways to have people work off different branches and automatically merge them when they commit as a trial integration, but that is a large amount of effort, and it can’t handle conflicts.
Agile principles
One of the “big dogs” in Agile is collaboration. Collaboration is pretty important. Working on separate branches tends to go against this idea. I know you can still collaborate when you have separate branches, but it is more likely that you won’t.
In general I have found that software developers in particular are the kinds of people who will go off and do their own thing if given the chance. It is not a bad thing, but it means that we need to set up developers to collaborate. If your process isn’t explicitly fostering collaboration, it probably won’t happen (at least not as much as you would like it to.)
If we are all working on the same branch we have to communicate. We have to work together to accomplish a goal. I can’t just work in isolation, because what I am doing affects you, and what you’re doing affects me. We have to talk about it.
I’m more likely to watch your code come in and say “hey, where is your unit test, bub?” You’re more likely to watch my code come in and say, “is there a reason you’re not using superWidgetX to solve that problem?”
If I check in some junk and break the build, everyone is impacted. This might seem like a bad thing, but it fosters a team mentality instead of an individual mentality. Think about boot camp (or at least what you have seen on TV.) What happens when one guy screws up? EVERYONE does push-ups. Why? To build a team, a team mentality.
I have found in Agile processes like Scrum, the best quality work is done when developers are paired up working on a backlog item. This isn’t impossible to do with individual developer branches or feature branches, but it is much harder and less likely to happen.
Keeping it simple
One of the central themes of my blog… of my life… is keeping it simple. Simple is good, it makes everything easier.
I am notorious for walking into an organization and ripping out all the ridiculous process that provides no value, and putting in very simple and lean process in its place. It is in my nature.
If you have ever spent some time in what I like to call “merge hell”, you’ll understand what I am about to talk about.
I have been working with source control for a very long time. I have been the “merge master”, merging huge numbers of branches together on large projects. I have worked on developer branches, feature branches, release branches and everything in-between, and I still can’t get it right!
Don’t get me wrong. I know the theory behind it, I know how to do it. But merging can be so complicated at times that the chance of making a mistake is very high.
You really have to ask yourself a question here: “Is all the overhead you are incurring from doing your complicated branching and merging strategy resulting in a real value that does not exist over a more simple strategy?”
My general rule of thumb is, never branch unless you have to.
A simple Agile branching strategy
In my next post, I will show you what I think is the most simple and effective branching strategy. A strategy I have effectively used in the past and have developed over time. I’ll sum it up briefly here.
- Everyone works off of trunk.
- Branch when you release code.
- Branch off a release when you need to create a bug fix for already released code.
- Branch for prototypes.
That’s it, stay tuned for next time when I talk about how to make this simple branching strategy practically work in your Agile environment.
As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple. Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week. Also, you can follow me on twitter here.
The post Simple Branching Strategy Part 1: Back to Basics appeared first on Making the Complex Simple.