continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@maven.org>
Subject Re: Release Management for Maven/Continuum
Date Wed, 23 Aug 2006 22:31:15 GMT

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




Mime
View raw message