A better release management strategy?

Question

I work for a company that makes a web based tool. As part of my job, I was given the task of release engineering for this product(something I had never done before). I've setup the following system using SVN(Sorry, we can't use another repository before someone suggests switching to GIT or perforce or one of the myriad of other options!)

Trunk is what is on the production servers at all times There are 2 branches open at any given time 1) Maintenance release. This is released every Wednesday 2) Sprint branch. This is released by weekly(on Wednesday with that weeks maint branch)

Prior to release I merge that weeks branches into the trunk.

I have found that when running svn merge, it usually creates a ton of problems when it merges. We have thus switched to a manual merging meeting once a week, which takes anywhere from 10 minutes to 1 hour, where I literally winmerge the 2 directories on my system and ask each developer "was this your change? which version of this code should we keep?"

This system definitely is NOT ideal.

Can someone suggest something better?

Answer 1

The statement "there are 2 branches open at any given time" is troublesome to me. At least in my practice branches are created for stabilization before a release or for bug fixing, and they are usually short lived.

My question is - what do you use the trunk for? It should not be what is on production, rather production should be running a tagged (therefore released) version.

Your merge problems are self-inflicted, as far as I can see.

Answer 2

First of all, SORRY! I don't envy your position.

I worked for an international bank doing web redesigns for the Federal Card Act. Same situation as you, only likely on a far larger scale. We had 3 people that did nothing but release management on a very similar schedule. The thing that made it do-able (in some weeks I worked with a couple hundred files at a time) was the fact that the developers merged to trunk, then trunk was deployed to production as a copy....we didn't check directly into production. So, from a release standpoint, you might be helping corral developers to get their work checked in (what's the difference between doing a "update" or answering "is this the right version?" really) But then you're not blindly choosing which updates should be going live, which seems like a major problem. Sure, developers might complain a bit, but having been in that position it's really not too bad. And if you make yourself available to answer any questions that might come up, it should be ok. It worked for the 1,200-odd developers we had working in 4 locations nationwide.

The other thing that this buys you is time to test. If code isn't merged before it goes live, how can it be tested in the context of the bigger system? I sure hope the answer isn't that it's not being tested!

Answer 3

The ideal branching strategy for this scenario is. Latest development in trunk and for every release cut a branch out of it and call it a maintainance release branch. However in your case maintainance release happens in trunk. Latest development happens in branch.

Keeping the branching strategy aside. Here are some suggestions to improve the current situation.

1. As the you say production related changes first happens in trunk, I assume it would be minimal. So why not you merge every production related change into these couple of other open branches on a frequent basis. I would say once a day, it can also be more frequent or less frequent. you will be able to better judge. This would also give better heads up to the developers the changes happening in production, reducing conflict. Also if there is a conflict this would be handled by the developers themselves on the branch.

2. You can think of coming up with some kind of framework

   • Should be able to define which are the branches which requires the commits made in trunk.

   • There can be a post commit hook script which will check if the commit is in trunk and do a svn merge right away with the branch and see if their is a conflict.

   • If the merge is successful, then commit the changes. Else mail the information to you and the appropriate developer who committed it(it depends on how you would want to deal with this).

Answer 4

Your trunk branch should contain all of the latest development code, which includes new and untested features and any code from other branches. It is very important that all code gets merged into this branch.

When you're ready (or think you're ready) for testing, create a stable branch off of your trunk branch. Use this branch for testing and fixing bugs only. Do not add any new features or improvements to your application here, or it might destabilize your existing code. Do not forget to merge changes made in this branch into your trunk branch.

When you're ready to release (your testing is complete), create a release branch off of your stable branch. This is the branch you release into production and maintain/support if bugs/issues are found in production. As with the stable branch, do not add anything new to this branch. This branch is usually tagged in order to identify it in production. Do not forget to merge changes made in this branch into the stable branch, so that other release branches created from the stable branch get the benefit of any bug fixes made.

The branch hierarchy will look like the following:

trunk
|-- stable 1.0
  |-- release 1.0
  |-- release 1.1
|-- stable 2.0
  |-- release 2.0

Using this hierarchy, your development team is free to develop in your trunk branch, while the stable and release branches allow for maintaining current and previous versions of your application.