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.
When ready for the release, branch for the release. If testers find issues, then they can fix the issue in the branch and merge it back to trunk so future work gets the fix too when possible.*
This gives you a relatively stable trunk, and a lot of unstable branches for the developers, with 'code freeze' branches for the testers and eventual release.
This won't resolve the merge conflicts - but the developers doing the merge should be able to manage it. It should also make the process relatively maintainable in the long run too.
Ben
* Sometimes you want a quick fix that you don't want to actually continue with b/c of having a better solution that takes longer to implement; in which case the release gets the quick fix and trunk gets the longer fix.
----- Original Message ----
From: Daniel Becroft <Daniel.Becroft_at_supercorp.com.au>
To: users_at_subversion.tigris.org
Sent: Monday, September 29, 2008 9:36:23 PM
Subject: Release Management
Hey
all,
We are
currently in the process of replacing our existing SCM with Subversion. We are
already using SVN for our new project(s), but are considering using it for our
current application as well. We have come against a process problem that we
can't seem to find a solution for. I thought I would ask the user community for
(a) past experiences and/or solutions; or (b) opinions/flak.
Our
application is approximately 6 million LOC, across about 6000 source code files
(many of which are no longer needed, but we had no file delete
handling).
** Current
model:
Our current
system uses a pessimistic locking approach. A developer will check-out (aka
lock) multiple files for a given ticket. No other developer can modify these
files until the ticket has been through the full testing cycle, and passed all
QAs (it can sometimes take several MONTHS before these files are available
again). When the testing is complete, these files are copied (in their entirety)
into the 'deployment' or 'staging' area. When we cut a patch or release, we
simply take the files in the staging area, compile, and ship. This is all a
single step process, with no manual intervention.
** New
model:
We are tried
to use SVN in the optimistic method (ie minimal locking, if any). We will have
one main development and one main release branch per version (1.00-development
&& 1.00-release, 1.01-development, etc).
-
Developers will do the normal check-out, modify, commit cycle on the
'development' branch for the required version.
-
Testers will use a checked-out version of the development branch for testing
purposes.
The problem
is: What is the easiest method of obtaining a version of deployed/tested code,
based on the deployed tickets Given that a file can be modified by multiple
developers now before being deployed, we should really only be shipping the
changes from the deployed tickets.
The solution
we have worked out so far involves the following:
1) Take a
copy of the last release/patch to be sent out.
2) Check the
eligible revisions to be merged to this branch.
3) If the
ticket for that revision has been deployed, then merge this change
across.
This doesn't
solve the merge conflicts problem (ie trying to merge r132 of a file without the
changes from r130). As a result, we can't get around the 'manual intervention'
issue with this..
Has anyone
had to deal with these situations before? How do other people manage releases
with SVN, and only shipping 'deployed' code?
NOTE: We
currently have no automated testing scripts in place, but this is on the
horizon.
Cheers,
Daniel
B.
Received on 2008-09-30 16:03:39 CEST