Advice on process for web development

Hi,

I'm working with our Web Team to re-engineer their development process. All the code is already under Subversion, but everything is in one big directory. They're not using any branch or tags for that matter. And of course, testing is not as rigorous and controlled as it should be. Anyway, I have suggested the usual trunk/branches/tags layout.

Developers will normally work on branches, but can occasionally work directly on trunk for easy and quick fixes. The tester will create a QA branch as a copy of trunk at a specific revision. When they are happy that a QA is ready for releasing, a tag is created from the QA (or maybe from trunk again at the same revision).

I think they will go for such a solution, even though it means that they cannot pick-and-choose what to test. If they want to test a bug fixed in revision 1000, they will also test all bugs fixed in previous revision.

The problem is that they may want to fast track an urgent bug fix. It shouldn't happen often, but it may happen so I need to come up with a solution for that case too.

What I'm thinking is something like the following. Let's supposed that 1.1 is the latest release, i.e. it's what's in production.
i) the developer creates a branch off the tag
        svn cp http://<URL TO REPO>/tags/1.1 http://<UR TO REPO>/branches/1.1_urgent_fix -m"Creating branch fro urgent bug 123456"
ii) the developer makes all the necesary, coding and testing
iii) the fix is merged back to trunk
        cd trunk
        svn merge ^/branches/1.1_urgent_fix .
        svn ci -m"Fixing urgent bug 123456"
iv) the branch goes live
        svn cp http://<URL TO REPO>/branches/1.1_urgent_fix http://<URL TO REPO>/tags/1.2 -m"Fixed bug 123456"
        switch the production site to point to ^/tags/1.2
v) at this point all the QA are useless because the do not contain the urgent fix, so a new QA must be created
        svn cp -rHEAD http://<URL TO REPO>/trunk http://<URL TO REPO>/tags/QA_1.3_1 -m"Created first QA for 1.3"

Now my questions.
1 - Do you have any comments on the process and/or any suggestions?
2 - Would the merge, in step iii, do the right thing and merge all revisions committed into the branch into trunk? I can't use --reintegrate becuase I haven't previously merged from trunk to the branch (as the branch was created as a copy of a tag).
3 - I don't really like the fact that after the fix has gone live, we are forced to create a QA from HEAD, which means testing everything that has gone into trunk, but I can't think of another way to make sure the fix is indeed included in the Qas and especially in the next (1.3 in this case) release.

Thank you in advance.

Giulio

Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
Received on 2010-10-29 14:20:44 CEST