> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> Sent: Wednesday, 1 October 2008 2:07 AM
> To: BRM
> Cc: Daniel Becroft; SubVersion Users
> Subject: Re: Release Management
>
> BRM wrote:
> > While I agree with Todd's comments, a few other thoughts...
> >
> > I would probably use a slight variation from what Todd suggested:
> >
> > 1. Stable trunk
> > 2. Developers work in their own branch for working 3.
> Testers work in
> > their own branch which becomes a specific release.
> >
> > So: Trunk is stable, developers branch from trunk to do their work,
> > and then merge the changes back in. This can be as micro or
> macro as
> > you like; but I would suggest that it be as micro as possible.
>
> And I'd do the opposite with all new development work
> possible except for disruptive changes done directly in the
> trunk so the developers can take advantage of each other's
> work instead of finding big incompatibilities when you try to
> merge their isolated changes.
That's essentially the model that we have decided upon. Except we aren't
developing on 'trunk'. Each release version has it's own conceptual
trunk. All work for this version will be done here first.
E.g.
tags\
trunk\
branches\
1.00-development
1.01-development
etc
As you said, any majorly disruptive changes will be done on a separate
branch, and merged later.
> With this model you would branch for each release, copying to
> tags for each QA build and releasing the tagged build that
> passes QA. If you do support updates of separate releases
> (instead of moving on the the next release), you would do
> that work on the branch that produced the corresponding
> tagged release repeating the tag/QA test process. Any way
> you do it, you will have some unavoidable work to fix a bug
> that spans supported revisions since you'll have to merge it
> to each branch that needs it.
Development work to move changes between versions is fine. WE have that
problem now, and so we can live with it.
Our testers are only ever testing a single piece of work, in relation to
the system. Ie, does new feature/change X work Y/N. If it does, then the
ticket is marked as deployed, and (in our old system), this code was
copied to the staging area. They aren't focussed on complete system
testing, until towards the end of the release cycle.
Because testing of a ticket only ever involved moving that ticket's code
into/out of the testing environment, then everything is fine. We know
that the code that is in the staging area has been tested, and so that
is our RC.
When using the SVN system, however, QAs will be using whatever has been
commited to the development branch (this assumes that the developer has
unit tested the work). If the QA's want to deploy the functionality, we
can't seem to figure out how/when to move that code (ie the changes for
that ticket) to the deployment environment. Do we move it right before
we cut the patch? Or when the ticket is completed testing? The latter
can result in more merge conflicts, the former results in more work for
the release manager (who, most likely, didn't do the coding in the first
place).
Our release process (atm) requires zero manual intervention, and we are
trying to achieve (if possible) the same result.
Unless I have something completely wrong (which is most likely).
<snip />
Cheers,
Daniel B.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-10-01 01:18:14 CEST