This entry is about utilizing branches for each developer in Subversion, Merge Day, and how while cool, it’s an ivory tower process.

Note: This isn’t a tenet of the Agile methodology itself, it’s just something that works well when you have a bunch of developers collaborating together rapidly, and a specific workflow our client requested we follow.

Branch Workflow

We’re utilizing a Branch Workflow on my current project.  What this means is that each developer creates their own branch in Subversion.  If you’re utilizing Tortoise SVN on PC or Versions on Mac, this is effectively a folder.  As you may know, Subversion has 3 default folders that you typically utilize in a repository, and hopefully each project gets its own repository.  These are branches, tags, and trunk.

Some people choose to ignore these.  Some put multiple projects into the same repo.  Both are fine because the mere fact people are utilizing source control in the first place, even if its just for disaster recovery, is great.

These folders, however, really do have a few reasons for their existence that have been well thought out.  Each source control system tries to out-do the next.  In Subversions case, the simple definitions are trunk is for the current version of your project, tags are for multiple older versions of your project, and branches are for experimental features or code that will possibly be merged back into trunk later.

Those are EXTREMELY simple definitions.  If you read the SVN book as well as other people who incorporate SVN into their workflow, the definitions and purposes can get quite complex.  For the project I’m currently on, branches take on a new meaning.  Not only are they where experimental code goes, but they each represent a user story.  Meaning, if I’m working on completing the user story where the user can modify their hardware device settings via a Flex form, that’ll go in it’s own branch.  Using source control to do this is pretty straight forward.  Instead of checking in here:

https://svn.server.com/repos/project/trunk/

You instead check-in here:

https://svn.server.com/repos/project/branches/sprint2/deviceform/

And the other developer with me would be working from:

https://svn.server.com/repos/project/branches/sprint2/registration/

Pretty easy right?  It gets even easier to check in.  No more, “Dude, have you checked your shiz in?” to another developer, or the cardinal rule of doing an update before checking in.  Now you can check in to your hearts content knowing it’s your own repo to abuse how you wish.

This has the side benefit of NOT breaking trunk… usually.  Again, the point of having frozen code you KNOW for a fact works is to use a tag, or a series of tagged builds.  A lot of developers get seriously bent out of shape if you break the trunk.  At one job, whoever broke the trunk had to use this monkey icon for their IM icon for one week.  It was funny until the 50th person asked why I had a silly monkey icon, and by that point, I was swearing I’d never break ANY trunk ever again.  This can possibly have the effect of keeping ‘em happy.  At the very least, this reduces the possibility of it happening because no one is working from trunk.

Instead, you check into trunk at the end of every sprint, or for my team, from Merge Day onwards.

Merge Day

Part of Agile is to have a day a few days before your UAT where everyone merges their working user stories into the same code base and “works out the kinks”.  Since everyone was coding in a different direction, this can be good and bad.  Good because they are working on completely unrelated things, but in GUI coding, we all know some things are extremely related.  Specifically, these are your data model in the form of ValueObjects, calls to a framework such as the use of Event classes in Cairngorm and PureMVC Mediators, and modifying settings in higher level view’s or CSS.

Since this can potentially have major consequences for some portions of a user story, or set of stories, it’s important to devote a pre-scheduled time where the team knows their code will be merged with everyone else’s code.  This is called Merge Day on my project and it happens every other Wednesday.  I take my branch and my co-workers, and merge his code into mine.  Then, I fix things that explode.  This could be as simple as just merging code over, or a complex verbal discussion to work towards resolving 2 different implementations.  No code is trivial.  If another developer added a style to MXML for example, setting the background color may seem small to you, but could be the difference between working or non-working code for the other developer’s code, so its important you do these merges together.

Once that is done, I merge into trunk, test again, fix explosions, and finally check in the working build.  I then upload a new build, or in the case of my current project, deploy a new build in a new sandbox utilizing Django’s web interface.  It can deploy to the web the latest bin-release that’s checked into SVN by merely clicking a button.  I’ll send an email to all members of the team identifying what’s new in the build.  This includes user stories, fixed bugs, and other things of note that are different from previous builds.

For fellow developers, this is a courtesy.  For Project Managers, it’s a necessity for them to set client expectations for Friday’s UAT.  For everyone it’s a Sprint milestone as well as reality check.  You can identify what user stories are done, which ones aren’t, what older ones you may have broken, and which current ones have issues.  You can then plan with your team what to spend the next day and a half on.  This is also where the rules can potentially break down.  What I’ll usually do is check my local copy into a new branch, and either fix partially completed or broken user stories, or just finish what I can.  The temptation here is to abandon branches since you only have a day and a half and it isn’t worth the trouble; just don’t break trunk in the meantime.

…riiiight.  The last thing you want to have happen the day before UAT is get all stressed out because trunk is broken.  To me, it’s worth the extra time in using the process to ensure your UAT prep goes smoothly.  I’m conservative.

I say that all high and mighty like, but on Sprint #2, I did just that.  Did I get lucky or was it just mad skillz?  Luck.

Conclusions

Now, all of the above processes could have been done with just utilizing trunk.  As you can hopefully see utilizing a branch for each developer, or multiple since creating a new folder is really easy, helps things go a lot smoother without surprises.  You can also plan for the chaos on Merge Day, which while extremely stressful for whoever is doing the merging, is at least expected and a concerted team effort.  I really have enjoyed the Branch Workflow so far.

…however, I don’t see it catching on.  Every Flash & Flex developer I’ve ever talked to doesn’t use branches.  Sam Robbins mentioned over Twitter they might start adopting this workflow at their place of work, and that’s great, but again, it seems to me most developers feel trunk is good enough and branches are just an unnecessary complication.

Stay tuned for #4 in the Agile Chronicles series where I talk about the POC (Proof of Concept), business strategy, and design challenges.