Michael Pickard wrote:
>> You really ought to create tags and build from those. You'll get the
>> "lockdown" you're after (only allow one person to create tags), get a
>> "snapshot" of the code at any time as a result for repeatable builds,
>> and you don't have to stop developers from committing at all.
>>
>
> OK, so let's say I create a tag and build for UAT from that.
> Dev A checks in some code,
> Dev B checks in some code,
> Dev A checks in some code,
> I'm notified of a failure in UAT and ask for a fix to be committed,
> Dev C checks in a fix
> I tag and build again.
>
> Isn't there a chance that the new build contains code submitted by A and
> B that may break an area of the codebase not covered by UAT ?
>
Hello Michael,
This is the exact same scenario that almost any development shop faces
for each release. While you could lock out other users during UAT,
Subversion and the copy-modify-merge model it is based on make it so
easy to do this sort of concurrent development that it would be a shame
to not take advantage of it.
At my employer, our more-or-less policy is that any time a build goes to
UAT, we first cut a branch, and build for UAT from that branch instead
of the trunk. That way, from your scenario, Dev A and B can continue to
check their code in to the trunk, while Dev C checks his bugfix into the
UAT branch. Anytime we do a new build to UAT, we merge those changes
back to the trunk. When UAT has finished and the changes go to
production, simply tag it, do a final merge of any last changes to
trunk, and delete the branch.
Of course, this approach also has its cons:
* Subversion currently has no real "merge tracking", meaning that as you
merge your changes from the UAT branch to the trunk, it's necessary to
keep track of what has already been merged so it isn't merged twice.
* It becomes necessary for developers to be more observant as to where
they are checking code into. Someone might accidentally check code into
the branch when they meant to check it into the trunk, or vice versa.
This could be solved with permissions of course, so that only one person
may actually make changes to the branch.
* It may result in conflicts when merging, although this is highly
unlikely in only a day. TortoiseSVN makes resolving conflicts very
straightforward although I've not found equally-good tools for other OSes.
So it's up to you whether the pros (no loss of dev time) outweigh the
cons. The problem is that any solution you use to temporarily restrict
access will likely turn into a pain very quickly, especially if there
are five different bugs found and you need to turn access on and off
repeatedly during that time (unless you take the approach of only
letting yourself make changes during UAT, but that will be a headache
for you as well).
I do know one thing though; if your UAT period is only one day then I'm
certainly jealous! If you continue to grow and take on more clients,
that one day may turn into days or weeks. When that happens, you'll be
glad that you have the branch-and-merge approach implemented!
Received on Mon Jul 24 21:53:41 2006