continuum-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Abley" <james.ab...@gmail.com>
Subject Re: Maven2 release process in Continuum
Date Thu, 19 Jul 2007 12:19:13 GMT
On 18/07/07, Mykel Alvis <mykel@weirdness.com> 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
>

Mime
View raw message