views:

256

answers:

2

Hi,

I hope this makes sense and apologies if this has been covered before.

The situation: We do regular releases to a production environment. At least once every two weeks, but quite often there can be up to three releases in a week. We have a focussed team of 3xSE's, 2xWD, 3xQA and a Technical Manager/Lead (me). The team fluctuates depending on the requirements, but we usually find that QA will dramatically increase in size towards the end to cope with delayed requirements/assets or a large regression testing phase. 6 standard feature branches which are usually targeted at release dates and a single trunk which doubles as the release branch. There is a merging and branching overhead but we have become pretty good at getting this down to a fine art. So we maintain branches by merging from trunk into the feature branch on a regular basis whenever there has been a merge into the trunk from one of the feature branches. This has provided us with the flexibility to allow our client to alter their requirements, pull back whole releases, etc without impacting too heavily on other elements of a release which are done in a separate branch.

The problem: I would like to look at ways to improve this process and we have examined the option of doing ALL work in a trunk repository, branching into a QA repository and then into a release branch. We would still be able to use feature branches if required from the trunk although this could be frowned upon. The point I have is that to bring two main elements of the site together, content and functionality, we would need to make things time dependent. I.e. provide a mechanism to put time dependency on the content (I'm not sure that you could on the functionality). The cost for this process will be relatively high and we would find out very quickly if it didn't work because we would not be able to respond to the client fast enough. Keep in mind that currently the client can review each of our feature branches as well as trunk in their separate UAT environments.

Does anyone have any suggestions or has encountered a similar situation before?

Thanks

+1  A: 

Are you using SVN 1.5, if you are i would take a serious look into the "svn merge --reintegrate" functionality.

zodeus
+1  A: 

Based on the scenario you described. I suggest moving experimental development to the main trunk and create release branches when you freeze features for a release. From that point on only introduce bug fixes into the release branch. Release branches can be left as long as necessary. No need to delete the branch after the release has shipped. (Of course doing so won't hurt. With SVN nothing is ever deleted permanently).

codeelegance