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.
Team 1 tags the build 1.1a.12 and Team 2 tags the build 1.1b.5 for testing.
QA approves 1.1b.5 as a release candidate with partial planned functionality
that our client will test. Development continues on both branches.
5 bugs in production are identified. We find that 2 of them are critical and
3 are not and will take some time to fix. We plan for two correction
releases, one for 2 days and another for 5 days. So we start only one new
branche called 1.0.1 both copied from tag 1.0.0.54.
Build 1.0.1.5 delivers planned fixes for version 1.0.1 and is approved for
releasing by the QA team. This tag is then merged into trunk with no
conflicts since there are no other changes committed to the trunk. Version
1.0.1.5 becomes our new baseline, which is reflected in trunk.
Branches 1.1a and 1.1b are now outdated and need to be rebased to include
changes to the baseline. Team 2 (1.1b) stops development and merge trunk
changes to its branch. Team 1 decides not to rebase now and development
continues. Client approved release candidate 1.1b.5 and wants it to go for
production with the partial functionality built.
Team 2 already made changes to 1.1.b branch. So they open a new branch
1.1.1.0 from tag 1.1.b.5 and merge the trunk to it. Team 2 notifies QA that
changes are not conflicting. QA makes regretion tests and finds no problem.
Branch 1.1.1.0 is merged to trunk and tag 1.1.1.0 is created. Software is
release to the client for final tests. Client approves it and the release
goes for production with new functionality.
Team 2 is up to date in it's 1.1b branch, Team 1 keeps apart from production
updates. Team 1 finishes developing their new features and gets build
1.1a.0.23 approved by QA functional tests. Now Team 1 decides to rebase
their work and merge the current trunk content to their 1.1a branch. They
solve conflicts and run unit tests OK. Since version 1.1 was already
released, they now copy their 1.1a branch to tag 1.2.0.24 and asks QA to
rerun all planned tests. Few bug fixes later, client tests OK, build
1.2.0.28 becomes the new release for production.
Changes applied to the trunk, branch 1.1a is deleted. Second fix package
finishes and build 1.2.1.0 is released. Trunk is updated once again. Team 2
decides to stop development, rename its branch to 1.3 and rebases it with
current trunk version. Next functional release will be 1.3 finishing all
planned development for this software.
Life goes on...
What you think?
-----Mensagem original-----
De: Giulio Troccoli [mailto:Giulio.Troccoli_at_uk.linedata.com]
Enviada em: sexta-feira, 29 de outubro de 2010 11:05
Para: 'lkimel_at_dba.com.br'
Cc: 'users_at_subversion.apache.org'
Assunto: RE: Advice on process for web development
CC-ing the list
> -----Original Message-----
> From: Luiz Guilherme Kimel [mailto:lkimel_at_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.Troccoli_at_uk.linedata.com]
> Enviada em: sexta-feira, 29 de outubro de 2010 09:20
> Para: users_at_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 -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 18:11:56 CEST