You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@continuum.apache.org by Jeremy Whitlock <jc...@gmail.com> on 2006/06/12 05:46:52 UTC
Release Management for Maven/Continuum
Continuum Dev,
I am currently working on a mechanism to have Maven's release plugin to
actuall use Continuum to perform the release process in a "Release
Management" type of usage. Jason Van Zyl and I have talked about this for
the last few days to flesh out the approach and here are the two Jira that
should get you up to speed with what I am doing:
http://jira.codehaus.org/browse/CONTINUUM-727
http://jira.codehaus.org/browse/MRELEASE-130
Jason has given me some good tips and such and I plan on starting this
tomorrow sometime. If any of you have any concerns, complaints or
suggestions, please let me know.
Take care,
Jeremy
Re: Release Management for Maven/Continuum
Posted by Brett Porter <br...@apache.org>.
With Archiva and Continuum both being webapps now, its should be
straightforward to deploy them both to your favourite container, and
as long as they are configured to utilise the same repository you'll
get what you need.
- Brett
On 25/08/2006, at 5:46 PM, Tomasz Pik wrote:
> I'm jumping into middle of discussion with some kind of separate
> (but not too
> separate) question/problem.
> As I understood Continuum should be located in some kind of
> 'dedicated' location,
> so it won't have influence on main development (developers decides,
> when to
> push new snapshot to shared repository, when perform release and so
> on,
> Continuum 'just check current versions').
> So (and maybe here I was wrong) Continuum should be separated from
> repositories.
> Now, if users will be able to perform releases through Continuum
> (which is
> a super thing), picture changes a bit.
> So my question is - will there be a possiblity to integrate Continuum
> and Archiva,
> so they may run together on one host/address/port/plexus instance?
> So both of them will make a kind of 'maven server'?
>
> Regards,
> Tomek
Re: Release Management for Maven/Continuum
Posted by Tomasz Pik <to...@gmail.com>.
I'm jumping into middle of discussion with some kind of separate (but not too
separate) question/problem.
As I understood Continuum should be located in some kind of
'dedicated' location,
so it won't have influence on main development (developers decides, when to
push new snapshot to shared repository, when perform release and so on,
Continuum 'just check current versions').
So (and maybe here I was wrong) Continuum should be separated from
repositories.
Now, if users will be able to perform releases through Continuum (which is
a super thing), picture changes a bit.
So my question is - will there be a possiblity to integrate Continuum
and Archiva,
so they may run together on one host/address/port/plexus instance?
So both of them will make a kind of 'maven server'?
Regards,
Tomek
Re: Release Management for Maven/Continuum
Posted by Brett Porter <br...@apache.org>.
> The original proposal was web services based, but the entire
> process occurring from Continuum is definitely useful. I think the
> concrete drivers are:
Right, so like other stuff there is a backend service, and it is
exposed in the same way to both a web interface and an xmlrpc client,
but neither depend on the other?
>
> 1) release:prepare from the CLI with the release plugin and pushing
> a release descriptor to Continuum. Then using the Continuum Web UI
> to perform the release.
> 2) talking to continuum via web services from an IDE to do the
> release:prepare. Then using the Continuum Web UI to perform the
> release.
> 3) talking to continuum via web services from an IDE to do both the
> release:prepare and release:perform.
> 4) the case noted above
>
> The the WEB UI needs to cleanly account for the separation so that
> the perform is not tied to the preparation being done in the web ui.
yes, good idea.
>
> - flesh out the release descriptor which is used for a release
yep, that's what I was referring to when I mention "model".
> - flesh out the release manager component and it can just delegate
> to the release plugin i suppose though separating a release manager
> component as has been discussed with Jeremy I think would be a good
> thing to do.
Is this the one in continuum that handles the backend of this
service, or are you referring to pulling all the code out of the
release plugin?
>
> For a multi module build when would you not use the parent? If you
> wanted a specific component that could be recorded in the release
> descriptor.
I think you'd always want the parent, but since we have no notion of
the association in Continuum I'm just wondering how it gets handled.
>
> A release build is different then what Continuum is typically doing
> so some separation I think would be wise so that in the UI release
> specific builds could be identified so possibly a separate queue
> with some different parameters so that release builds can't be
> interfered with.
I'm not sure what you mean here, we generally need builds to be
separate and not interfered with (for example, when we start building
on two different JDKs on the same instance we'll want to make sure
they don't conflict - I view that as the same thing)
>
> I think we should think about this now instead of hacking out
> something. Jeremy and Edwin seem to have some time so let's address
> all the points outlined above. Have some feedback on design, which
> shouldn't take long, and then implement.
+1 to design first.
I'm not sure we need to worry about build queues in this iteration,
though. That could get right down into the continuum internals.
Anyway, I'll leave that up to Edwin and Jeremy.
>
> I think as long as all the design, which I'm sure both Jeremy and
> Edwin will contribute to, is out on the table and we all agree then
> they can work out the implementation. I think as they are both
> relatively new contributors this is the best course forward.
>
+1
- Brett
Re: Release Management for Maven/Continuum
Posted by Jason van Zyl <ja...@maven.org>.
On 23 Aug 06, at 10:02 AM 23 Aug 06, Brett Porter wrote:
> Finally getting around to replying :)
>
> I spoke to Edwin on IRC and he's proposed the following steps:
> 1) go to the project group...
> 2) then click on the release project icon ( a new icon )
> 3) then a page will prompt for the release version and the next dev
> version...
> 4) after filling the required parameters, click the prepare for
> release button...
> 5) the page after the procedure is either a progress or an auto-
> refreshing page, i'm still open )
> 6) when the release prepare is a success, then a button for the
> perform release is shown
> 7) otherwise, some kind of a build failure report will be shown
> 8) and repeat 6/7 during perform release
>
The original proposal was web services based, but the entire process
occurring from Continuum is definitely useful. I think the concrete
drivers are:
1) release:prepare from the CLI with the release plugin and pushing a
release descriptor to Continuum. Then using the Continuum Web UI to
perform the release.
2) talking to continuum via web services from an IDE to do the
release:prepare. Then using the Continuum Web UI to perform the release.
3) talking to continuum via web services from an IDE to do both the
release:prepare and release:perform.
4) the case noted above
The the WEB UI needs to cleanly account for the separation so that
the perform is not tied to the preparation being done in the web ui.
> So this part is pretty straightforward. For 3) the webwork
> modeldriven action can be used against the modello model to easily
> produce a form page. For 5) the WW showcase has a "run in
> background, show page and refresh" example that could be used,
> though I consider that a nice to have.
>
> There seems to be a pretty good base with the current model. I
> think the tasks that are needed in the release plugin:
> - add any missing elements to the model
> - change the release mojos to marshal arguments to this instead of
> the current configuration classes and pass that into the release
> process
> - need to retain the ability to prompt for those not specified as
> happens now, so the prepare(Release) method will be new. Continuum
> will set the mojo into non-interactive mode to ensure this doesn't
> happen.
>
- flesh out the release descriptor which is used for a release
- flesh out the release manager component and it can just delegate to
the release plugin i suppose though separating a release manager
component as has been discussed with Jeremy I think would be a good
thing to do.
> And in continuum its wiring up the steps as above. Edwin was going
> to make adjustments to the white site to be able to visualise this
> before diving in.
>
Cool, I think Jeremy has some general ideas too and Edwin and Jeremy
can sort out how they want to implement the details.
> The tricky things that might need more discussion:
> - how are multi-module projects handled in Continuum? I think for
> this incarnation we go with the simple solution which is to just
> trigger it on the project on its merits (so if its the parent, the
> whole lot is released)
>
For a multi module build when would you not use the parent? If you
wanted a specific component that could be recorded in the release
descriptor.
> - how is the project built? Is it queued into Continuum, or are the
> same tools used to run a separate build in the background?
>
> - what files are modified? the current checkout in Continuum, or a
> clean one? If it is the current one, builds need to be locked out
> while the release process is in progress.
>
A release build is different then what Continuum is typically doing
so some separation I think would be wise so that in the UI release
specific builds could be identified so possibly a separate queue with
some different parameters so that release builds can't be interfered
with.
> I think the short term solution is to go with a clean checkout and
> doing it all in the background, separate from the continuum build
> queue. This seems the easiest.
Separate from the standard CI queue but I think a release queue would
be appropriate. Then we could leverage all the reporting and screens
for builds in queues.
>
> In the long term, has Continuum becomes more feature rich, I would
> rather see it is a queued build with certain settings enabled
> (clean checkout, clean repository) so that other features such as
> monitoring the scheduling could be reused.
>
Ok, I should just read ahead :-)
I think we should think about this now instead of hacking out
something. Jeremy and Edwin seem to have some time so let's address
all the points outlined above. Have some feedback on design, which
shouldn't take long, and then implement.
> Thoughts?
>
> How could the work be partitioned up so that both interested people
> can work on it effectively?
I think as long as all the design, which I'm sure both Jeremy and
Edwin will contribute to, is out on the table and we all agree then
they can work out the implementation. I think as they are both
relatively new contributors this is the best course forward.
>
> Cheers,
> - Brett
>
> On 12/06/2006, at 1:46 PM, Jeremy Whitlock wrote:
>
>> Continuum Dev,
>> I am currently working on a mechanism to have Maven's release
>> plugin to
>> actuall use Continuum to perform the release process in a "Release
>> Management" type of usage. Jason Van Zyl and I have talked about
>> this for
>> the last few days to flesh out the approach and here are the two
>> Jira that
>> should get you up to speed with what I am doing:
>>
>> http://jira.codehaus.org/browse/CONTINUUM-727
>> http://jira.codehaus.org/browse/MRELEASE-130
>>
>> Jason has given me some good tips and such and I plan on starting
>> this
>> tomorrow sometime. If any of you have any concerns, complaints or
>> suggestions, please let me know.
>>
>> Take care,
>>
>> Jeremy
>
Jason van Zyl
jason@maven.org
Re: Release Management for Maven/Continuum
Posted by Brett Porter <br...@apache.org>.
On 24/08/2006, at 12:17 AM, Joakim Erdfelt wrote:
> Some thoughts.
>
> I could see the need to go back into the build history and creating
> a release off of an older build to be quite likely too.
>
absolutely. I think Jason has talked about checking in the release
model and tagging that in the past. Future feature :)
It should really work off of a pure SCM URL + tag if needed in most
cases though.
> Also, should the locking of the project be at the Continuum/
> filesystem side, or on the SCM side? If scm side, we should add
> supportsLock()/lock()/unlock() support to maven-scm soon.
I thought this was already implemented in the API and used by the
release plugin (and configurable).
Anyway, that would be nice but I was referring to locking on the
Continuum side to prevent builds getting into the queue when you are
using its checkout.
>
> As for multi-module, make it context sensitive as you describe.
> Example:
> maven/trunk/components/ = full maven release process (multi-module)
> maven/trunk/wagon/wagon-providers/ = wagon providers only release
> (multi-module)
> maven/trunk/jxr/ = jxr release (single module)
>
Yep, but we really need to revise the entire multi-module story
across Continuum. It needs to be possible to operate on them as a
unit, but also as individuals, and I don't want that concept tied to
the groups as that could hopefully be more arbitrary. But I digress...
> Might prove useful on a multi-module to display/show the affected
> projects/scm's on the prepare release screen as a confirmation to
> the user of the release process to use.
+1
>
> Also, about security, we definitely need to setup a ROLE for this
> functionality.
>
Well, the work is on trunk, where there aren't any of the new roles
yet. Was the list of permissions that was started on the wiki completed?
/me puts lid back on can of worms :)
- Brett
Re: Release Management for Maven/Continuum
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
Some thoughts.
I could see the need to go back into the build history and creating a
release off of an older build to be quite likely too.
Also, should the locking of the project be at the Continuum/filesystem
side, or on the SCM side? If scm side, we should add
supportsLock()/lock()/unlock() support to maven-scm soon.
As for multi-module, make it context sensitive as you describe.
Example:
maven/trunk/components/ = full maven release process (multi-module)
maven/trunk/wagon/wagon-providers/ = wagon providers only release
(multi-module)
maven/trunk/jxr/ = jxr release (single module)
Might prove useful on a multi-module to display/show the affected
projects/scm's on the prepare release screen as a confirmation to the
user of the release process to use.
Also, about security, we definitely need to setup a ROLE for this
functionality.
- Joakim Erdfelt
Brett Porter wrote:
> Finally getting around to replying :)
>
> I spoke to Edwin on IRC and he's proposed the following steps:
> 1) go to the project group...
> 2) then click on the release project icon ( a new icon )
> 3) then a page will prompt for the release version and the next dev
> version...
> 4) after filling the required parameters, click the prepare for
> release button...
> 5) the page after the procedure is either a progress or an
> auto-refreshing page, i'm still open )
> 6) when the release prepare is a success, then a button for the
> perform release is shown
> 7) otherwise, some kind of a build failure report will be shown
> 8) and repeat 6/7 during perform release
>
> So this part is pretty straightforward. For 3) the webwork modeldriven
> action can be used against the modello model to easily produce a form
> page. For 5) the WW showcase has a "run in background, show page and
> refresh" example that could be used, though I consider that a nice to
> have.
>
> There seems to be a pretty good base with the current model. I think
> the tasks that are needed in the release plugin:
> - add any missing elements to the model
> - change the release mojos to marshal arguments to this instead of the
> current configuration classes and pass that into the release process
> - need to retain the ability to prompt for those not specified as
> happens now, so the prepare(Release) method will be new. Continuum
> will set the mojo into non-interactive mode to ensure this doesn't
> happen.
>
> And in continuum its wiring up the steps as above. Edwin was going to
> make adjustments to the white site to be able to visualise this before
> diving in.
>
> The tricky things that might need more discussion:
> - how are multi-module projects handled in Continuum? I think for this
> incarnation we go with the simple solution which is to just trigger it
> on the project on its merits (so if its the parent, the whole lot is
> released)
>
> - how is the project built? Is it queued into Continuum, or are the
> same tools used to run a separate build in the background?
>
> - what files are modified? the current checkout in Continuum, or a
> clean one? If it is the current one, builds need to be locked out
> while the release process is in progress.
>
> I think the short term solution is to go with a clean checkout and
> doing it all in the background, separate from the continuum build
> queue. This seems the easiest.
>
> In the long term, has Continuum becomes more feature rich, I would
> rather see it is a queued build with certain settings enabled (clean
> checkout, clean repository) so that other features such as monitoring
> the scheduling could be reused.
>
> Thoughts?
>
> How could the work be partitioned up so that both interested people
> can work on it effectively?
>
> Cheers,
> - Brett
>
> On 12/06/2006, at 1:46 PM, Jeremy Whitlock wrote:
>
>> Continuum Dev,
>> I am currently working on a mechanism to have Maven's release
>> plugin to
>> actuall use Continuum to perform the release process in a "Release
>> Management" type of usage. Jason Van Zyl and I have talked about
>> this for
>> the last few days to flesh out the approach and here are the two Jira
>> that
>> should get you up to speed with what I am doing:
>>
>> http://jira.codehaus.org/browse/CONTINUUM-727
>> http://jira.codehaus.org/browse/MRELEASE-130
>>
>> Jason has given me some good tips and such and I plan on starting this
>> tomorrow sometime. If any of you have any concerns, complaints or
>> suggestions, please let me know.
>>
>> Take care,
>>
>> Jeremy
>
Re: Release Management for Maven/Continuum
Posted by Jan Nielsen <Ja...@sungardhe.com>.
FWIW, this sounds good to me, Jeremy.
-Jan
Jan Nielsen * System Architect * SunGard Higher Education * Tel +1 801 257
4155 * Fax +1 801 485 6606 * jan.nielsen@sungardhe.com * 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.
"Jeremy Whitlock" <jc...@gmail.com>
08/24/2006 05:51 PM
Please respond to
continuum-dev@maven.apache.org
To
continuum-dev@maven.apache.org
cc
Subject
Re: Release Management for Maven/Continuum
Hi all,
After talking with Jason I have started on phase 1 of this venture.
Phase 1 is as follows:
1. Create a model for Maven to use for the release descriptor
2. Integrate the model into the Maven release plugin
I know...it seems too simple but that should be phase 1. What this will
do
is allow Maven to use a Java object, which can be persisted to a file like
XML, to store the model. Why is this important? Once we want to have
Continuum be able to perform the release it is as simple as sending the
release descriptor object to Continuum to do the work and return a status.
Phase 2 will start with Continuum facing things which will get Continuum
capable of performing the release and returning a release status object.
This phase will also be used to update the web interface to be able to
perform releases based on the guidelines Brett and Jason have discussed in
this email.
Phase 3 will be to modify the Maven release plugin model to allow for
Continuum bits to be stored in the model and used to delegate the release
process to Maven. This process will also involve having Maven handle the
release status object returned.
How does this sound? It is pretty high level and does not discuss or
outline any of the lower level details.
Take care,
Jeremy
P.S. - This email is the result of Jason and I talking so if I butchered
what was discussed, please let me know Jason.
On 8/24/06, Jan Nielsen <Ja...@sungardhe.com> wrote:
>
> 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 * jan.nielsen@sungardhe.com *
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 <br...@apache.org>
> 08/23/2006 10:37 PM
> Please respond to
> continuum-dev@maven.apache.org
>
>
> To
> continuum-dev@maven.apache.org
> 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
>
>
>
Re: Release Management for Maven/Continuum
Posted by Jeremy Whitlock <jc...@gmail.com>.
Hi all,
After talking with Jason I have started on phase 1 of this venture.
Phase 1 is as follows:
1. Create a model for Maven to use for the release descriptor
2. Integrate the model into the Maven release plugin
I know...it seems too simple but that should be phase 1. What this will do
is allow Maven to use a Java object, which can be persisted to a file like
XML, to store the model. Why is this important? Once we want to have
Continuum be able to perform the release it is as simple as sending the
release descriptor object to Continuum to do the work and return a status.
Phase 2 will start with Continuum facing things which will get Continuum
capable of performing the release and returning a release status object.
This phase will also be used to update the web interface to be able to
perform releases based on the guidelines Brett and Jason have discussed in
this email.
Phase 3 will be to modify the Maven release plugin model to allow for
Continuum bits to be stored in the model and used to delegate the release
process to Maven. This process will also involve having Maven handle the
release status object returned.
How does this sound? It is pretty high level and does not discuss or
outline any of the lower level details.
Take care,
Jeremy
P.S. - This email is the result of Jason and I talking so if I butchered
what was discussed, please let me know Jason.
On 8/24/06, Jan Nielsen <Ja...@sungardhe.com> wrote:
>
> 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 * jan.nielsen@sungardhe.com * 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 <br...@apache.org>
> 08/23/2006 10:37 PM
> Please respond to
> continuum-dev@maven.apache.org
>
>
> To
> continuum-dev@maven.apache.org
> 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
>
>
>
Re: Release Management for Maven/Continuum
Posted by Brett Porter <br...@apache.org>.
At the risk of oversimplifying, you are saying you need two things:
- a descriptor that lists all the files and their versions that make
up the release, independent of SCM tag
- a descriptor that describes how the software was built (versions of
everything)
The first is basically an SCM independent tagging mechanism, right?
The second is going to be required whether you use the above or you
use a "real" tag. Is that correct?
The second has been on our "to do" list for some time surrounding the
release plugin. There was some prior support but it didn't work
perfectly. It's definitely needed for reproducible builds,
independently of what Continuum needs.
The first sounds like an interesting thing to add to Maven SCM and
utilise from the release process as you've described (as a
preliminary, recorded "tag" that can be applied to the SCM later).
I think both of these are possibilities, but since they are generally
useful they should be implemented elsewhere first and integrated into
this feature. They'll fit in with the design that's being put
together here.
Cheers,
Brett
On 26/08/2006, at 4:18 AM, Jan Nielsen wrote:
> Hi Brett,
>
> (Sorry, this got longer than I thought it would...)
>
> Yes; the "build labeling" would be a nice addition.
>
> I may be missing an important point in the release management
> process that
> is being discussed so if you will endulge me, let me try to clarify my
> understanding, so you can help me understand the discussion.
>
> I think there are two important aspects which defines a "release":
> persistent meta-information identifying /what/ defines the release,
> and a
> reproducible process defining /how/ to produce the release. With this
> information, it is possible to (re-)generate an arbitrary release,
> and to
> branch an arbitrary release producing a new release related to that
> previous release (assuming the files and tools used for the release
> are
> still available).
>
> As you note, there are two different broad tactics for generating a
> release: "tag-pull-build-publish", and "pull-build-publish[-tag]". The
> "tag" is an SCM operation which defines the set of files to operate on
> ("build labeling"); the "pull" is an SCM operation to get files
> from SCM;
> the "build" is a build server operation to generate binaries from the
> source from SCM; and "publish" is distribution of the resultant binary
> (which may include test cycles, internal publication, etc.).
>
> The "tag-pull-build-publish" scheme has the benefit of having the SCM
> define the /"what"/ of the release; it generally does not define the
> /"how"/ until you combine the process with something like Maven and
> Continuum which has a defined process for the /"how"/. The drawback is
> that the "tag" process can be lengthy and possibly very broad.
>
> The "pull-build-publish[-tag]" scheme has the benefit of being the
> same
> process that we go through as for any other build with the
> exception that
> the /"what"/ is now not simply what is in the SCM system right now,
> but
> rather is something very specific, e.g., "a/b/c.java#34, a/b/d.java#2,
> etc.", as specified in the "release descriptor". Since the release
> descriptor defines exactly what is in the release, we can "tag" at any
> later time without impacting the development cycle.
>
> For example, project "A" has two files a.java and a.xml. The
> project has
> been building for a while producing builds 12, 13, etc. The build 12
> contains a.java#4 and a.xml#23, along with its meta data files, to
> wit:
>
> A#12: a.java#4, a.xml#23 pom.xml#22 profile.xml#3 settings.xml#5
>
> (this reads build 12 of project "A" contains "a.java" version 4 and
> "a.xml" version 23) and subsequent builds:
>
> A#13: a.java#5, a.xml#23 pom.xml#22 profile.xml#3 settings.xml#5
> A#14: a.java#6, a.xml#24 pom.xml#22 profile.xml#3 settings.xml#5
> A#15: a.java#6, a.xml#25 pom.xml#22 profile.xml#3 settings.xml#5
>
> In general, the "tag-pull-build-publish" crowd would do:
>
> tag "1.0" to all A#14 files
> pull all "1.0" files
> build
> publish
>
> In general, the "pull-build-publish[-tag]" crowd would do:
>
> pull all A#14 files
> build
> publish
> optionally tag all A#14 files with "1.0"
>
> One way to implement this is to add a "release" button here:
>
> http://people.apache.org/~epunzalan/continuum-white-site/index.html
>
> so you would have "Build Now | Release Now | Build and Release | Build
> History | Working Copy | Delete".
>
> By pressing the "Release", Continuum would ask the release engineer
> provide a "release tag", and then do the "pull-build-publish[-tag]"
> operations. By pressing the "Tag and Release", Continuum would ask the
> release engineer provide a "release tag", and then do the
> "tag-pull-build-publish" operations. In both modes, Continuum is
> rebuilding the build that the CI cycle already built. This process can
> probably be made more elegant.
>
> The "A#14" is the "release descriptor" but it needs to fleshed out,
> as was
> mentioned. It should include full descriptions of the tools
> required to
> reproduce the build, e.g., Maven version numbers, Continuum version
> numbers, Ant version numbers, JDK version numbers, OS version numbers,
> etc.
>
> Thoughts?
>
>
> -Jan
>
>
> Jan Nielsen * System Architect * SunGard Higher Education * Tel +1
> 801 257
> 4155 * Fax +1 801 485 6606 * jan.nielsen@sungardhe.com *
> 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 <br...@apache.org>
> 08/24/2006 09:41 PM
> Please respond to
> continuum-dev@maven.apache.org
>
>
> To
> continuum-dev@maven.apache.org
> cc
>
> Subject
> Re: Release Management for Maven/Continuum
>
>
>
>
>
>
> Hi Jan,
>
> The release is indeed modifying the pom, tagging the code, and doing
> a full build and deploy cycle of that code to produce a formal
> release.
>
> I think there is definitely room for another feature which I've
> always referred to as "build labeling" where you take the existing
> continuum build, label it as a certain milestone, and then if it
> passes into the final release stage goes through the build/tag
> procedure.
>
> Some organisations like to do the opposite and tag every build and
> then its just a matter of picking which is final. So the two would
> need to cooperate.
>
> - Brett
>
> On 25/08/2006, at 1:41 AM, Jan Nielsen wrote:
>
>> 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 * jan.nielsen@sungardhe.com *
>> 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 <br...@apache.org>
>> 08/23/2006 10:37 PM
>> Please respond to
>> continuum-dev@maven.apache.org
>>
>>
>> To
>> continuum-dev@maven.apache.org
>> 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
>>
>
Re: Release Management for Maven/Continuum
Posted by Jan Nielsen <Ja...@sungardhe.com>.
Hi Brett,
(Sorry, this got longer than I thought it would...)
Yes; the "build labeling" would be a nice addition.
I may be missing an important point in the release management process that
is being discussed so if you will endulge me, let me try to clarify my
understanding, so you can help me understand the discussion.
I think there are two important aspects which defines a "release":
persistent meta-information identifying /what/ defines the release, and a
reproducible process defining /how/ to produce the release. With this
information, it is possible to (re-)generate an arbitrary release, and to
branch an arbitrary release producing a new release related to that
previous release (assuming the files and tools used for the release are
still available).
As you note, there are two different broad tactics for generating a
release: "tag-pull-build-publish", and "pull-build-publish[-tag]". The
"tag" is an SCM operation which defines the set of files to operate on
("build labeling"); the "pull" is an SCM operation to get files from SCM;
the "build" is a build server operation to generate binaries from the
source from SCM; and "publish" is distribution of the resultant binary
(which may include test cycles, internal publication, etc.).
The "tag-pull-build-publish" scheme has the benefit of having the SCM
define the /"what"/ of the release; it generally does not define the
/"how"/ until you combine the process with something like Maven and
Continuum which has a defined process for the /"how"/. The drawback is
that the "tag" process can be lengthy and possibly very broad.
The "pull-build-publish[-tag]" scheme has the benefit of being the same
process that we go through as for any other build with the exception that
the /"what"/ is now not simply what is in the SCM system right now, but
rather is something very specific, e.g., "a/b/c.java#34, a/b/d.java#2,
etc.", as specified in the "release descriptor". Since the release
descriptor defines exactly what is in the release, we can "tag" at any
later time without impacting the development cycle.
For example, project "A" has two files a.java and a.xml. The project has
been building for a while producing builds 12, 13, etc. The build 12
contains a.java#4 and a.xml#23, along with its meta data files, to wit:
A#12: a.java#4, a.xml#23 pom.xml#22 profile.xml#3 settings.xml#5
(this reads build 12 of project "A" contains "a.java" version 4 and
"a.xml" version 23) and subsequent builds:
A#13: a.java#5, a.xml#23 pom.xml#22 profile.xml#3 settings.xml#5
A#14: a.java#6, a.xml#24 pom.xml#22 profile.xml#3 settings.xml#5
A#15: a.java#6, a.xml#25 pom.xml#22 profile.xml#3 settings.xml#5
In general, the "tag-pull-build-publish" crowd would do:
tag "1.0" to all A#14 files
pull all "1.0" files
build
publish
In general, the "pull-build-publish[-tag]" crowd would do:
pull all A#14 files
build
publish
optionally tag all A#14 files with "1.0"
One way to implement this is to add a "release" button here:
http://people.apache.org/~epunzalan/continuum-white-site/index.html
so you would have "Build Now | Release Now | Build and Release | Build
History | Working Copy | Delete".
By pressing the "Release", Continuum would ask the release engineer
provide a "release tag", and then do the "pull-build-publish[-tag]"
operations. By pressing the "Tag and Release", Continuum would ask the
release engineer provide a "release tag", and then do the
"tag-pull-build-publish" operations. In both modes, Continuum is
rebuilding the build that the CI cycle already built. This process can
probably be made more elegant.
The "A#14" is the "release descriptor" but it needs to fleshed out, as was
mentioned. It should include full descriptions of the tools required to
reproduce the build, e.g., Maven version numbers, Continuum version
numbers, Ant version numbers, JDK version numbers, OS version numbers,
etc.
Thoughts?
-Jan
Jan Nielsen * System Architect * SunGard Higher Education * Tel +1 801 257
4155 * Fax +1 801 485 6606 * jan.nielsen@sungardhe.com * 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 <br...@apache.org>
08/24/2006 09:41 PM
Please respond to
continuum-dev@maven.apache.org
To
continuum-dev@maven.apache.org
cc
Subject
Re: Release Management for Maven/Continuum
Hi Jan,
The release is indeed modifying the pom, tagging the code, and doing
a full build and deploy cycle of that code to produce a formal release.
I think there is definitely room for another feature which I've
always referred to as "build labeling" where you take the existing
continuum build, label it as a certain milestone, and then if it
passes into the final release stage goes through the build/tag
procedure.
Some organisations like to do the opposite and tag every build and
then its just a matter of picking which is final. So the two would
need to cooperate.
- Brett
On 25/08/2006, at 1:41 AM, Jan Nielsen wrote:
> 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 * jan.nielsen@sungardhe.com *
> 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 <br...@apache.org>
> 08/23/2006 10:37 PM
> Please respond to
> continuum-dev@maven.apache.org
>
>
> To
> continuum-dev@maven.apache.org
> 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
>
Re: Release Management for Maven/Continuum
Posted by Brett Porter <br...@apache.org>.
Hi Jan,
The release is indeed modifying the pom, tagging the code, and doing
a full build and deploy cycle of that code to produce a formal release.
I think there is definitely room for another feature which I've
always referred to as "build labeling" where you take the existing
continuum build, label it as a certain milestone, and then if it
passes into the final release stage goes through the build/tag
procedure.
Some organisations like to do the opposite and tag every build and
then its just a matter of picking which is final. So the two would
need to cooperate.
- Brett
On 25/08/2006, at 1:41 AM, Jan Nielsen wrote:
> 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 * jan.nielsen@sungardhe.com *
> 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 <br...@apache.org>
> 08/23/2006 10:37 PM
> Please respond to
> continuum-dev@maven.apache.org
>
>
> To
> continuum-dev@maven.apache.org
> 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
>
Re: Release Management for Maven/Continuum
Posted by Jan Nielsen <Ja...@sungardhe.com>.
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 * jan.nielsen@sungardhe.com * 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 <br...@apache.org>
08/23/2006 10:37 PM
Please respond to
continuum-dev@maven.apache.org
To
continuum-dev@maven.apache.org
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
Re: Release Management for Maven/Continuum
Posted by Brett Porter <br...@apache.org>.
> 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
Re: Release Management for Maven/Continuum
Posted by Edwin Punzalan <ep...@exist.com>.
I'll be updating the white-site...
Please see my inline comments below
Brett Porter wrote:
> Feedback:
> - I'd rather Release be equivalent to "build now" (ie, we might need
> an icon for it), so added to the right-hand tasks per project, and
> added to the individual project page as a button.
>
> - I don't think this should operate on a group. It doesn't necessarily
> equate to a multi-module project, so instead I'd just go project by
> project. If they hit the parent then they get to release a bunch at
> once, as is the case in maven
>
Above is what we've talked about in IRC and its fine with me. Makes
things simpler, too.
> - I like the summary page that lists out all the defaults, however
> instead of an "edit" link, how about making the whole thing a form
> with defaults that gets submitted?
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.
>
> - I don't think we should have checkboxes on which modules to release,
> as that doesn't really correspond to what we have now, and likewise
> the "from parent" checkbox wouldn't be relevant
I get what you mean, so ok.
>
> - there will be more elements to configure - we should get them into
> the interface now
I'll try to put them all in the next white-site
>
> - on prepare finished, it should look like the build result page. We
> are only building one thing if you agree with the above
>
> - likewise for perform
>
> - as Jason said, prep and perform should be separate. I'm not sure of
> the best way to do this - perhaps hitting the release button presents
> the following options:
> * prepare release from current code
> * perform release from (list of previously prepared releases that
> haven't been performed)
> * perform release from SCM tag
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.
<snip>
Re: Release Management for Maven/Continuum
Posted by Brett Porter <br...@apache.org>.
Feedback:
- I'd rather Release be equivalent to "build now" (ie, we might need
an icon for it), so added to the right-hand tasks per project, and
added to the individual project page as a button.
- I don't think this should operate on a group. It doesn't
necessarily equate to a multi-module project, so instead I'd just go
project by project. If they hit the parent then they get to release a
bunch at once, as is the case in maven
- I like the summary page that lists out all the defaults, however
instead of an "edit" link, how about making the whole thing a form
with defaults that gets submitted?
- I don't think we should have checkboxes on which modules to
release, as that doesn't really correspond to what we have now, and
likewise the "from parent" checkbox wouldn't be relevant
- there will be more elements to configure - we should get them into
the interface now
- on prepare finished, it should look like the build result page. We
are only building one thing if you agree with the above
- likewise for perform
- as Jason said, prep and perform should be separate. I'm not sure of
the best way to do this - perhaps hitting the release button presents
the following options:
* prepare release from current code
* perform release from (list of previously prepared releases that
haven't been performed)
* perform release from SCM tag
- I think prepare should not be started if the build is currently in
error in continuum.
WDYT?
On 24/08/2006, at 1:41 AM, elpunzalan wrote:
>
> Thanks brett for posting that.
>
> white-site is available at
> http://people.apache.org/~epunzalan/continuum-white-site/
> groupStatus.html.
>
> It does not comply 100% with what brett and I have discussed, but
> it does
> give the flexibility to release the whole project group or just a
> selected
> few... which kind'a gives us an idea on how continuum will be
> working on
> multi-project releases.
>
> I agree that the release process would be a separate background
> execution
> bec releases should be a closely monitored procedure.
>
>
>
> brettporter wrote:
>>
>> Finally getting around to replying :)
>>
>> I spoke to Edwin on IRC and he's proposed the following steps:
>> 1) go to the project group...
>> 2) then click on the release project icon ( a new icon )
>> 3) then a page will prompt for the release version and the next dev
>> version...
>> 4) after filling the required parameters, click the prepare for
>> release button...
>> 5) the page after the procedure is either a progress or an auto-
>> refreshing page, i'm still open )
>> 6) when the release prepare is a success, then a button for the
>> perform release is shown
>> 7) otherwise, some kind of a build failure report will be shown
>> 8) and repeat 6/7 during perform release
>>
>> So this part is pretty straightforward. For 3) the webwork
>> modeldriven action can be used against the modello model to easily
>> produce a form page. For 5) the WW showcase has a "run in background,
>> show page and refresh" example that could be used, though I consider
>> that a nice to have.
>>
>> There seems to be a pretty good base with the current model. I think
>> the tasks that are needed in the release plugin:
>> - add any missing elements to the model
>> - change the release mojos to marshal arguments to this instead of
>> the current configuration classes and pass that into the release
>> process
>> - need to retain the ability to prompt for those not specified as
>> happens now, so the prepare(Release) method will be new. Continuum
>> will set the mojo into non-interactive mode to ensure this doesn't
>> happen.
>>
>> And in continuum its wiring up the steps as above. Edwin was going to
>> make adjustments to the white site to be able to visualise this
>> before diving in.
>>
>> The tricky things that might need more discussion:
>> - how are multi-module projects handled in Continuum? I think for
>> this incarnation we go with the simple solution which is to just
>> trigger it on the project on its merits (so if its the parent, the
>> whole lot is released)
>>
>> - how is the project built? Is it queued into Continuum, or are the
>> same tools used to run a separate build in the background?
>>
>> - what files are modified? the current checkout in Continuum, or a
>> clean one? If it is the current one, builds need to be locked out
>> while the release process is in progress.
>>
>> I think the short term solution is to go with a clean checkout and
>> doing it all in the background, separate from the continuum build
>> queue. This seems the easiest.
>>
>> In the long term, has Continuum becomes more feature rich, I would
>> rather see it is a queued build with certain settings enabled (clean
>> checkout, clean repository) so that other features such as monitoring
>> the scheduling could be reused.
>>
>> Thoughts?
>>
>> How could the work be partitioned up so that both interested people
>> can work on it effectively?
>>
>> Cheers,
>> - Brett
>>
>> On 12/06/2006, at 1:46 PM, Jeremy Whitlock wrote:
>>
>>> Continuum Dev,
>>> I am currently working on a mechanism to have Maven's release
>>> plugin to
>>> actuall use Continuum to perform the release process in a "Release
>>> Management" type of usage. Jason Van Zyl and I have talked about
>>> this for
>>> the last few days to flesh out the approach and here are the two
>>> Jira that
>>> should get you up to speed with what I am doing:
>>>
>>> http://jira.codehaus.org/browse/CONTINUUM-727
>>> http://jira.codehaus.org/browse/MRELEASE-130
>>>
>>> Jason has given me some good tips and such and I plan on starting
>>> this
>>> tomorrow sometime. If any of you have any concerns, complaints or
>>> suggestions, please let me know.
>>>
>>> Take care,
>>>
>>> Jeremy
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Release-
> Management-for-Maven-Continuum-tf1771971.html#a5947006
> Sent from the Continuum - Dev forum at Nabble.com.
Re: Release Management for Maven/Continuum
Posted by elpunzalan <el...@gmail.com>.
Thanks brett for posting that.
white-site is available at
http://people.apache.org/~epunzalan/continuum-white-site/groupStatus.html.
It does not comply 100% with what brett and I have discussed, but it does
give the flexibility to release the whole project group or just a selected
few... which kind'a gives us an idea on how continuum will be working on
multi-project releases.
I agree that the release process would be a separate background execution
bec releases should be a closely monitored procedure.
brettporter wrote:
>
> Finally getting around to replying :)
>
> I spoke to Edwin on IRC and he's proposed the following steps:
> 1) go to the project group...
> 2) then click on the release project icon ( a new icon )
> 3) then a page will prompt for the release version and the next dev
> version...
> 4) after filling the required parameters, click the prepare for
> release button...
> 5) the page after the procedure is either a progress or an auto-
> refreshing page, i'm still open )
> 6) when the release prepare is a success, then a button for the
> perform release is shown
> 7) otherwise, some kind of a build failure report will be shown
> 8) and repeat 6/7 during perform release
>
> So this part is pretty straightforward. For 3) the webwork
> modeldriven action can be used against the modello model to easily
> produce a form page. For 5) the WW showcase has a "run in background,
> show page and refresh" example that could be used, though I consider
> that a nice to have.
>
> There seems to be a pretty good base with the current model. I think
> the tasks that are needed in the release plugin:
> - add any missing elements to the model
> - change the release mojos to marshal arguments to this instead of
> the current configuration classes and pass that into the release process
> - need to retain the ability to prompt for those not specified as
> happens now, so the prepare(Release) method will be new. Continuum
> will set the mojo into non-interactive mode to ensure this doesn't
> happen.
>
> And in continuum its wiring up the steps as above. Edwin was going to
> make adjustments to the white site to be able to visualise this
> before diving in.
>
> The tricky things that might need more discussion:
> - how are multi-module projects handled in Continuum? I think for
> this incarnation we go with the simple solution which is to just
> trigger it on the project on its merits (so if its the parent, the
> whole lot is released)
>
> - how is the project built? Is it queued into Continuum, or are the
> same tools used to run a separate build in the background?
>
> - what files are modified? the current checkout in Continuum, or a
> clean one? If it is the current one, builds need to be locked out
> while the release process is in progress.
>
> I think the short term solution is to go with a clean checkout and
> doing it all in the background, separate from the continuum build
> queue. This seems the easiest.
>
> In the long term, has Continuum becomes more feature rich, I would
> rather see it is a queued build with certain settings enabled (clean
> checkout, clean repository) so that other features such as monitoring
> the scheduling could be reused.
>
> Thoughts?
>
> How could the work be partitioned up so that both interested people
> can work on it effectively?
>
> Cheers,
> - Brett
>
> On 12/06/2006, at 1:46 PM, Jeremy Whitlock wrote:
>
>> Continuum Dev,
>> I am currently working on a mechanism to have Maven's release
>> plugin to
>> actuall use Continuum to perform the release process in a "Release
>> Management" type of usage. Jason Van Zyl and I have talked about
>> this for
>> the last few days to flesh out the approach and here are the two
>> Jira that
>> should get you up to speed with what I am doing:
>>
>> http://jira.codehaus.org/browse/CONTINUUM-727
>> http://jira.codehaus.org/browse/MRELEASE-130
>>
>> Jason has given me some good tips and such and I plan on starting this
>> tomorrow sometime. If any of you have any concerns, complaints or
>> suggestions, please let me know.
>>
>> Take care,
>>
>> Jeremy
>
>
--
View this message in context: http://www.nabble.com/Release-Management-for-Maven-Continuum-tf1771971.html#a5947006
Sent from the Continuum - Dev forum at Nabble.com.
Re: Release Management for Maven/Continuum
Posted by Brett Porter <br...@apache.org>.
Finally getting around to replying :)
I spoke to Edwin on IRC and he's proposed the following steps:
1) go to the project group...
2) then click on the release project icon ( a new icon )
3) then a page will prompt for the release version and the next dev
version...
4) after filling the required parameters, click the prepare for
release button...
5) the page after the procedure is either a progress or an auto-
refreshing page, i'm still open )
6) when the release prepare is a success, then a button for the
perform release is shown
7) otherwise, some kind of a build failure report will be shown
8) and repeat 6/7 during perform release
So this part is pretty straightforward. For 3) the webwork
modeldriven action can be used against the modello model to easily
produce a form page. For 5) the WW showcase has a "run in background,
show page and refresh" example that could be used, though I consider
that a nice to have.
There seems to be a pretty good base with the current model. I think
the tasks that are needed in the release plugin:
- add any missing elements to the model
- change the release mojos to marshal arguments to this instead of
the current configuration classes and pass that into the release process
- need to retain the ability to prompt for those not specified as
happens now, so the prepare(Release) method will be new. Continuum
will set the mojo into non-interactive mode to ensure this doesn't
happen.
And in continuum its wiring up the steps as above. Edwin was going to
make adjustments to the white site to be able to visualise this
before diving in.
The tricky things that might need more discussion:
- how are multi-module projects handled in Continuum? I think for
this incarnation we go with the simple solution which is to just
trigger it on the project on its merits (so if its the parent, the
whole lot is released)
- how is the project built? Is it queued into Continuum, or are the
same tools used to run a separate build in the background?
- what files are modified? the current checkout in Continuum, or a
clean one? If it is the current one, builds need to be locked out
while the release process is in progress.
I think the short term solution is to go with a clean checkout and
doing it all in the background, separate from the continuum build
queue. This seems the easiest.
In the long term, has Continuum becomes more feature rich, I would
rather see it is a queued build with certain settings enabled (clean
checkout, clean repository) so that other features such as monitoring
the scheduling could be reused.
Thoughts?
How could the work be partitioned up so that both interested people
can work on it effectively?
Cheers,
- Brett
On 12/06/2006, at 1:46 PM, Jeremy Whitlock wrote:
> Continuum Dev,
> I am currently working on a mechanism to have Maven's release
> plugin to
> actuall use Continuum to perform the release process in a "Release
> Management" type of usage. Jason Van Zyl and I have talked about
> this for
> the last few days to flesh out the approach and here are the two
> Jira that
> should get you up to speed with what I am doing:
>
> http://jira.codehaus.org/browse/CONTINUUM-727
> http://jira.codehaus.org/browse/MRELEASE-130
>
> Jason has given me some good tips and such and I plan on starting this
> tomorrow sometime. If any of you have any concerns, complaints or
> suggestions, please let me know.
>
> Take care,
>
> Jeremy