Sorry for jumping in here but I'm not entirely sure I understand the
big-picture process you are describing. Is the only difference
between a
"build" and a "release" the presence of meta-data describing what you
built the release from (and possibly the life-time of that meta-data)?
If so, one way to implement a "release" is to "tag" everything with
some
release moniker, e.g., "1.0", and then retrieve all these tagged
files,
then build it, and then publish it as your "release 1.0". This has the
obvious benefit of using the SCM system to track release numbers,
but the
drawback that some SCM systems take along time to perform the tag
operation and it requires a two step build procedure, tag-and-
build, which
is not the normal build cycle. For releases spanning multiple
modules this
scheme become complex and very broad. (Is the intent of the
"prepare" step
to perform the "tag" SCM operation?) To recover a past release
build, you
then use the SCM to retrieve the "tagged" files - easy enough.
Another way is denote a release is to capture the meta-data of
files in
the build, and dependent modules, and then check-in this release
descriptor with the release tag. The drawback to this scheme is
obviously
that the SCM store no longer directly identifies the set of files
with an
explicit release number. But the benefit is that no single "tag"
operation
needs to be done on the entire file set before the build and the
built set
of files is collected after the build operation which can be now be
done
for each build. The release descriptor will then contain the uniquely
identifying information for all files built, collected after the SCM
update operation, and all release descriptors of dependent modules. To
recover a past build, you then use the SCM to get the release
descriptor
and from the release descriptor pull the appropriate POM and files
from
the SCM - this is now a two step procedure, but these two steps
could be
automated.
As you may have guessed, each of our builds is a "release" which
enables
us after QC completes to define build 12345 as "Release 1.0" (and
once the
release has been defined, you could go back and "tag" each file in the
build with the release moniker if you really want the SCM to hold this
information explicitedly).
I hope I didn't stir the water. Thoughts?
-Jan
Jan Nielsen * System Architect * SunGard Higher Education * Tel +1
801 257
4155 * Fax +1 801 485 6606 * [EMAIL PROTECTED] *
www.sungardhe.com
* 90 South 400 West, Suite 500, Salt Lake City, UT USA
CONFIDENTIALITY: This email (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited. If you received this email in error,
please notify the sender and delete this email from your system. Thank
you.
Brett Porter <[EMAIL PROTECTED]>
08/23/2006 10:37 PM
Please respond to
[email protected]
To
[email protected]
cc
Subject
Re: Release Management for Maven/Continuum
The summary page shows only a few of the release parameters. So the
"Edit" link is there to direct the user to the more detailed
release configuration page. But since we'll be releasing projects
one at a time, I guess I can incorporate what you mean into the new
white-site.
Just to be clear - if the single project that is released has
modules, there will be multiple entries on this page.
I think it should be a big long form, though, because it would be
tedious to change individual values project per project when you need
to edit them like that (unless we get all ajax, but that might be a
separate UI initiaive)
ok, so this means continuum should remember prepared releases.
Should there be a separate release working directory for this?
Because a prepared release may get lost after a scheduled build.
A prepared release is simply a tag in the SCM, I think (you might
want to double check that that is all release:perform reads back from
the release properties).
Basically what wuld happen here, after fleshing out the model, is
that it would replace the configuration store in the release plugin
(so you could use Xpp3Reader/Writer to store release.xml instead of
release.properties), and the same thing could be used to store a
release's information in the database, along with the information
here.
Anyway, maybe I'm going overboard on that, but its something to think
about.
- Brett
