Branching per feature

// August 27th, 2009 // Linux, Programming

If you’re working in an Agile environment, chances are you’re working from a continuously integrated source control system, with a trunk, branches etc… If that’s the case many people will be familiar with “the build” being broken (typically the trunk) which can bring development (and sometimes testing) to a grinding halt. The larger the team(s) the more likely this is. I’ve recently been giving thought to branching per feature. The concept isn’t quite ready yet, but I thought I’d share my ideas and see if anyone can add to them (or shoot them down).

The Concept

It’s a commonly done concept, and more people are thinking about it, for example Derick Bailey has recently started posting on the same topic to which I’ve already fired some responses. Here’s an overview.

  1. Cut a branch – For every feature (or possibly story if they are of a reasonable size) a separate branch is cut.
  2. Work on the branch – A team of developers works from that branch
  3. Test the branch – Ideally once coded, the feature is then tested on that branch.
  4. Commit - Once complete (remember “dev complete” is not complete), it’s merged into the trunk.

Advantages

  • Time/cost saving – The “build” shouldn’t break as much, which means development will have less interruptions. Especially cross-team as teams will be working on their own branches.
  • Releases - The trunk should typically always be releasable. This means once a feature is complete and approved, you can potentially release it, rather than waiting until the end of an iteration. This allows you to deliver to your customer more quickly, and reap the rewards sooner. You can still release on a per iteration basis if you wish, it just gives more flexibility.
  • Rollbacks - If you fail to meet your commitment, you don’t need to roll anything back or cut it out of the trunk as it won’t have been committed to the trunk. All saving more developer time.
  • Dropping work – Work on features can easily be halted (should priorities change) and left without impacting the trunk.

Disadvantages

  • Assigning work – Work needs to be handed out carefully between teams. If both teams are working on exactly the same pieces of code but on separate branches, you’re increasing the chances of conflicts happening when merging to the trunk.
  • Merging – related to the above point, when committing a feature you could run into complications. Conflicts, breaking tests etc… but I guess that comes down to being careful when merging.
  • Environments - Setting up different environments for each branch is potentially quite painful or complicated.

The Pains Of Subversion

Ignoring TFS, Subversion is one of, if not the most commonly used source control system. The above concept is possible using Subversion, but it can potentially be painful.

  • Branching – every branch has to be made on the server, and then checked out. Not having the ability to make local branches makes additional work and bloats the server.
  • Commits – all commits have to go to the server. Something like Git allows local (remote) commits, and pushes between local repositories (remote working).
  • Merging – something that can be quite painful with Subversion. This can lead to things being wrongly merged, and as a subsequence, introduce bugs. We’ve had huge pains with this before. There’s nothing worse than being unsure if you’re merges were 100% correct.

What’s Required

  • Move To Git - as mentioned above, it solves some of the problems with Subversion. Namely easier branching, local commits, pushing between local repositories, more intelligent merging. Plus TortoiseGit has come a long way, and now has nearly all the similar functionality of TortoiseSvn. Unfortunately there’s not a VisualGit though. It’s a big move switching source control system, but there are plenty of ways to get all of your code and logs across from Subversion into Git.
  • Vertical Partitioning – If the code base is heavily mixed, and there are a lot of dependencies throughout it, it may prove harder to do branching per feature. However, switching to Git encourages lots of smaller repositories (because you can’t do sub folder checkouts, only root checkouts), which itself pushes you towards vertical partitioning. So after switching to Git, you will need to clean up the archtecture and organsiation of your projects and code.
  • Setting Up Environments – this is something I haven’t thought about much, as the feature will need to be tested. One solution is to, once the feature is dev complete merge it into the trunk for testing. I’m not sure if this is ideal though, it would be better if the feature could be completely finished (ie including testing) before committing it. For environments a SQL database needs to be setup, and IIS configured. This needs some thought. If it becomes additional work and a pain, then the benefits of the whole concept disappear as you’ve reduced work in one area, and created more in another. Another solution would be to set up a number of dev environments, ie dev1, dev2, dev3, etc… and you pick one when developing a feature.
  • Cool Deployment Script – if you are working from a local branch, or server branch, and need to deploy to a certain server. It’ll mean creating a reasonably clever build script to pull the files from the specified repository, compile them (just as normal) and deploy them to the specified server (shouldn’t be too hard to make it dynamic).
  • Database Test Data – if testers are having to switch between dev1, dev2, etc… for testing it can be annoying to lose, or have different test data on each environment. Some thought needs to be given to sync’ing data between instances, resetting data, pushing new data around etc…

Conclusion

I won’t list too many other things as I could easily go on. It does show there’s a fair amount of ground work to be done. You could even skip some steps, for example you don’t have to switch to Git. And there’s a lot of experimentation that needs to be done. I run Git at home, and am doing the above already, but applying it at work requires planning and small iterative steps. I’ll cover more about this in another post, but for now I’m trialling a set of 20 or so use-cases for Tortoise Git (to make sure it can do all the things we typically do), and breaking apart our main Subversion repository. Oh, and hosting Git in Windows, that’s a whole lot of fun! :)

Leave a Reply