On 18/07/07, Mykel Alvis <[EMAIL PROTECTED]> wrote:
> 1) There is potential for me to check in the release version, start
> preparing the release and then someone else checks out the release
> version and starts doing stuff to it, when they should really be
> waiting until the next SNAPSHOT version has been checked in. I guess I
> can use locking for that, but it's been a while since I used locking
> with a SCM (been on CVS, SVN and Bazaar for a while - not used
> SourceSafe in four years or so).
I personally prefer releasing manually over getting an automation
system to do that. IMO, that's just not what CI servers like
continuum are made to do. Too many things can go awry in the course
of a build and recovering from a release that failed partway through
is a pain in the ass.
There's always locking, but our current strategy is to branch the code
to do releases. We use subversion, which makes branching (and
tagging) very cheaply. We currently are releasing about 40 of our
100+ artifacts, and the current strategy denotes a few things:
a) the /tags and /branches belong to the build engineer (me). The
developers are free to branch and tag in the /userbranches and
/usertags paths.
b) a number version (major.minor.release).
c) release along a branch for customer-facing releases, Thus for
component "foo" at version 1.0.0-SNAPSHOT, to release I create a
branch called (literally) "foo-1.0.x" that releases all versions
following the pattern "1.0.x". I then switch the head of the trunk to
"1.1.0-SNAPSHOT" and let everyone continue on their merry path. When
we release that version, we'll branch again to a branch called
"foo-1.1.x"
d) when a minor version gets deprecated, it's just never released
again. We don't delete anything, since it's subversion and difficult
to really delete from anyway.
e) parent poms are never snapshots for the developers. I spent a good
deal of time getting them right and I check and recheck changes to
them before I make parent pom releases. This is probably only
reasonable since my primary job is managing the build.
Since I use a property built in the parent pom with elements
over-ridden in child poms to build the scm strings for subversion, I
generally only have to change a few properties to get my new branch
built by continuum. I do that when I branch the code.
Updating the poms by hand for the new versions? Well, that's just the
price of admission for a non-modular build. I've had some problems
with modular builds over the years and I tend to avoid them, but given
the amount of time it's taking to do our releases, I'm starting to
give them thought again.
> 2) Kind of related to that - the need for some sort of development
> freeze during that day. We don't want that.
Release along a branch in subversion solves this, but that initial
branching adds significant time. Enough to effectively more than
double our total release time.
> Should it really be taking me a day to do a release of this scale or
> am I doing something fundamentally wrong?
Unless we're both on the wrong road, I think you're pretty much
following the path. It takes me about 13 hours to do a full
soup-to-nuts release of our 40-ish projects for the final assembly.
Most of that time is spent checking for incorrect dependencies that
the developers have missed. Fortunately, my parent poms for our
projects have improved dramatically, so we're no longer releasing
parent poms in the course of a normal release. Parents belong
exclusively to me so I release them when needed and get the developers
to update to the new parents a few days prior to release (hopefully).
That gives me a couple of days of instability to make sure I didn't
screw up the build by releasing a new parent.
Hope some of this helps.
Mykel
Thanks for your comments. Some good ideas for me to chew over, and I
think that I will be sticking to the release plugin to release our
stuff; maybe scripting it in a suitable language (probably Python?) or
contributing patches to the plugin to try to avoid so many manual
steps.
James
