Note: if you meant to post this on the list, you didn't. I'm including
your entire text along with my response for the benefit of the group.
> -----Original Message-----
> From: Rob van Oostrum [mailto:rvanoo@gmail.com]
>
> I am a full-time build guy, and I've done feature-branching
> on web projects where we'd have half a dozen or more active
> branches at any one time, and production releases every day,
> every other day, or sometimes multiple times a day.
>
> Each feature branch would hold changes related to one or more
> bug/enhancement/feature tickets, and they would get
> "committed" to the release stream (a branch usually called
> "maintenance") only when we had QA signoff on the feature
> branch. In some cases there would be 2 QA stages: one after
> work on the feature branch was thought to be complete, and
> once that had passed, the branch would be merged with
> production changes since the branch was created (i.e.
> re-baselined to production), and a second round of QA would
> be done. Usually this would be because there was a
> significant lag between work being completed and the
> scheduled release of the branch.
Okay, so your teams do their work on feature branches, wherein you have
several developers working together on that branch. There is no
code-review/audit/process in the middle of their work while they're
hacking away. However, when the time comes after unit testing and
debugging produces a reasonable product, your team steps back and lets
the QA team go over it with a fine-toothed comb.
They would merge that with production updates and ensure the merge
didn't break anything, at which point the result would either become the
next production deployment, or be merged into a codeline that becomes
the next deployment.
Meanwhile, other teams are working on other features. Some made it into
the same production release yours did, others did not. The ones that
did not would then merge or "rebase" with the production-level code and
continue their work until the next cycle comes around.
Is that right?
>
> After a production release was done successfully, and a smoke
> test of production revealed no new problems, the maintenance
> branch would either be merged back to trunk, but after a
> while we would replace trunk with the maintenance branch to
> save ourselves the headache.
>
> FYI this was a 4-5GB or so working copy type codebase, with
> anywhere from a couple to a dozen people actively
> contributing at any point in time. There would typically be a
> couple of longer-term feature release type projects on the
> go, and as much as a dozen or more smaller bug
> fixes/enhancements going live on any given day. We were
> running 2 QA environments, 2 UAT environments, and different
> sets of changes would be put through their respective paces
> on any or all of those at the same time.
>
> During any given week, I would also be responsible for the
> same on up to a dozen other albeit smaller accounts.
>
> There is nothing about Subversion in and of itself that makes
> this exercise difficult let alone impossible. It certainly
> worked well for us. Not having the tool do more of the
> process enforcement and housekeeping for you (a la
> ClearCase/ClearQuest) can be a problem if you don't have a
> single owner (i.e. a Build Manager) who is not also one of
> the developers. Being in the loop on expectations being set
> with clients also helps, since that's where breakdowns in
> proces are usually born (e.g. a PM caving in to pressure from
> client prior to validating with his/her team that doing X
> amount of work in Y amount of time is even physically
> possible; sometimes what's best for a client is to get less
> 'stuff' and avoid a ripple effect of trying to play catchup
> while not losing ground on the never-ending flow of new
> work), and it only goes south from there. In my experience
> anyway, this is a human problem long before it ever becomes a
> technical one, and it wouldn't be fair to blame the tool for
> not being perfect when all else falls apart.
>
> Sorry for the length, but I hope this is what you were looking for.
>
> R.
It is exactly what I'm seeking. We're reviewing SCM products now, and
the other option on our table is Surround. It has lots of bells and
whistles, including "code statuses" (which seem quite a bit like
"promotion groups" from Serena), and nifty workflow examples for optimum
marketing. One example that is fresh in my mind is the workflow in
which everything a developer commits goes in with a status of "needs
review", and a hook emails some "reviewer" who then goes in and reviews
it. If no problems are seen, it is promoted to whatever (say "QA"),
etc.
I'm curious about people's experience with these kinds of features - are
they helpful, or do they make life hellish?
>
> On 10/17/07, Bicking, David (HHoldings, IT)
> <David.Bicking@thehartford.com> wrote:
> > I'm curious - do any of you use Subversion for complex workflow
> > management of software development? For example,do you
> have processes
> > where developers check-in code, and it doesn't really get
> "committed"
> > until someone else reviews it and lets it pass? How
> complex is your
> > environment?
> >
> >
> > --
> > David
> >
> >
> >
> **********************************************************************
> > *** This communication, including attachments, is for the exclusive
> > use of addressee and may contain proprietary, confidential and/or
> > privileged information. If you are not the intended recipient, any
> > use, copying, disclosure, dissemination or distribution is strictly
> > prohibited. If you are not the intended recipient, please
> notify the
> > sender immediately by return e-mail, delete this communication and
> > destroy all copies.
> >
> **********************************************************************
> > ***
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 17 22:58:33 2007