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 -mCreating 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 -mFixing 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 -mFixed 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 -mCreated 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
RE: Advice on process for web development
CC-ing the list -Original Message- From: Luiz Guilherme Kimel [mailto:lki...@dba.com.br] Sent: 29 October 2010 15:44 To: Giulio Troccoli Subject: RES: Advice on process for web development Giulio, I would recommend you a reference book for SCM patterns. Try ADDISON WESLEY Software Configuration Management Patterns. It has solutions Answering your questions, you need to stablish baselines for your software. Branches will have one baseline as their common start point, as their base. This base will usually be a stable version of your software. Let's say your baseline is exactly your current production release. What you're saying is that the branches should be created as copies of trunk at a specific revision, i.e. the production one. Have I understood correctly? Sometimes your baseline will evolve. Maybe because your QA team approved some new features for production, maybe because you made urgent corrections. If it's approved for production it will be your new baseline. All branches from this baseline will need to be rebased before releasing, they need to incorporate any production changes. So, basically, I need to merge changes in trunk from the previous production revision to the current production revision (which may not be HEAD at all) to the branches. Your correction will be tested isolated, approved and merged to your trunk for tagging and release. If your development branches are based on the trunk, then you will need to merge trunk changes to each development branch to rebase them. Use the development branch for integration so that the next approved branch will always merge to the trunk with no possibility of conflict. After rebasing, apply new QA tests. I'm not sure I understand you here. After the development in a branch has been completed, the branch is tested and if approved merged back into the trunk. Surely though I need to test trunk as well. I didn't say, but yes when a branch is reintegrated into the trunk, the other branches should merge from trunk to get those changes. Why your QA team have a branch??? They won't ever make changes, so all they need is a tag. I mean, in SVN it's the samething, but in the concept it's a lot different. The QA team does not have a branch. I realised I said create a QA branch as a copy of trunk but then in the command I did create the branch in tags. Which doesn't mean that they cannot change it, but it will be prevented and, as you said, conceptually is different. Do you already use any project management and bug tracking tool? If not, I would recommend MantisBT. We do. It's actually part of what the Web Team does. Thanks for your input, however, you haven't touched on the main issues I have, which is about the case of an urgent fix. Giulio Best Regards, Luiz Guilherme M. Kimel -Mensagem original- De: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] Enviada em: sexta-feira, 29 de outubro de 2010 09:20 Para: users@subversion.apache.org Assunto: 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 -mCreating 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 -mFixing 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 -mFixed 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
Re: Advice on process for web development
On 10/29/2010 9:04 AM, Giulio Troccoli wrote: Sometimes your baseline will evolve. Maybe because your QA team approved some new features for production, maybe because you made urgent corrections. If it's approved for production it will be your new baseline. All branches from this baseline will need to be rebased before releasing, they need to incorporate any production changes. So, basically, I need to merge changes in trunk from the previous production revision to the current production revision (which may not be HEAD at all) to the branches. Or just make different 'cuts' from the trunk to new QA branches, which, if everything works can be copied unchanged to production tags. If you have to make changes in QA, you have to make an additional decision as to whether the fix needed there also applies to the ongoing trunk, and if so, merge it - or maybe it has already been done on the trunk. Why your QA team have a branch??? They won't ever make changes, so all they need is a tag. I mean, in SVN it's the samething, but in the concept it's a lot different. If things never change between the cut from trunk and the production release, what's the point of the QA step? It is possible, in fact likely, that you'll need changes for a release after the trunk has moved on to include things you don't want in this release. The QA team does not have a branch. I realised I said create a QA branch as a copy of trunk but then in the command I did create the branch in tags. Which doesn't mean that they cannot change it, but it will be prevented and, as you said, conceptually is different. If you made a tag for QA you can always copy it out to a branch after discovering it needs changes. Thanks for your input, however, you haven't touched on the main issues I have, which is about the case of an urgent fix. If you had a QA branch corresponding to each release, you'd have an obvious place to make maintenance fixes specific to that release. But that doesn't solve your problem of making sure the fix also is done in the trunk - unless you do the work on the trunk and merge to the branch to add the fix. How you do that needs to be a human decision, not driven by the process. If the process could solve all your problems you wouldn't need this urgent fix in the first place, you'd have caught it in QA. Since it is something unexpected, you need to understand it and figure out separately how it relates to the now-different trunk. -- Les Mikesell lesmikes...@gmail.com -- Les Mikesell lesmikes...@gmail.com
Re: RES: Advice on process for web development
On 10/29/2010 12:10 PM, Luiz Guilherme Kimel wrote: Let me try explain it better... Let's say I just built the first version of an application, so I don't currently have any branch, just the trunk where a small team of developers were working until now. Our last build was tagged as 1.0.0.54 meaning it's our 54 build of the 1.0 version. The QA team approved this build and it becomes our first release of the software. Tag 1.0.0.54 is our baseline which is equal to our trunk at that moment. Now we have two new modules to develop in parallel. The team will receive more people to speed up next releases, so we decided to start working with branches. Two new branches are created: /branches/1.1a and /branches/1.1b. Trunk is locked. Only reading is allowed. Developers are allowed to write only on branches. What do you gain by making 2 branches instead of continuing one line of development on the trunk and the one that would be disruptive to it on a branch? -- Les Mikesell lesmikes...@gmail.com
RES: RES: Advice on process for web development
Nothing if you don't have concurrent new features development lines. If you can predict serial updates, then you won't need to branch. It's the first option, it's less complex: one mainline of development, branching only for emergency corrections from production tags. But, if you have concurrent development efforts that can be stopped, change in priority, take long time to be validated by a client etc, then I think branching for feature and updating the trunk only with stable code that needs to be spread turns everything easier and cleaner. If you have many different clients for a single product, it may gets hard to know which new feature will be released first. Clients will not always obey to plans and clients may change their mind in what is priority and what is not. -Mensagem original- De: Les Mikesell [mailto:lesmikes...@gmail.com] Enviada em: sexta-feira, 29 de outubro de 2010 14:00 Para: users@subversion.apache.org Assunto: Re: RES: Advice on process for web development On 10/29/2010 12:10 PM, Luiz Guilherme Kimel wrote: Let me try explain it better... Let's say I just built the first version of an application, so I don't currently have any branch, just the trunk where a small team of developers were working until now. Our last build was tagged as 1.0.0.54 meaning it's our 54 build of the 1.0 version. The QA team approved this build and it becomes our first release of the software. Tag 1.0.0.54 is our baseline which is equal to our trunk at that moment. Now we have two new modules to develop in parallel. The team will receive more people to speed up next releases, so we decided to start working with branches. Two new branches are created: /branches/1.1a and /branches/1.1b. Trunk is locked. Only reading is allowed. Developers are allowed to write only on branches. What do you gain by making 2 branches instead of continuing one line of development on the trunk and the one that would be disruptive to it on a branch? -- Les Mikesell lesmikes...@gmail.com
