Hi,
one thing that has been bothering me for a while is the time it takes to make
a release of the two projects out of the stable series, I normally have to
spend 4 hours to make it.
The current situation, with the cite tests running every night, is certainly better
than it was once, but there is still a lot of work to do, and that work has to
be done by someone that has all the keys to the project administration areas.
Sometimes I’d like to delegate the release to some of my colleages at
work that might have a few spare hours, but they don’t even have commit
access so that is not feasible.
Any suggestions on what we could do to improve the release process?
The ideal-ideal situation would be something like a customized hudson build
that given the release notes and the branch name does it all, making the packages
available for upload to sourceforge and the like.
But any way to further shrink the release times would be welcomed
Cheers
Andrea
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
The current situation, with the cite tests running every night, is certainly better
than it was once, but there is still a lot of work to do, and that work has to
be done by someone that has all the keys to the project administration areas.
In a perfect world the maven release target would work and take care of tagging etc. We could then place that in hudson and ask someone to poke the button (and make the JIRA release notes).
Sometimes I’d like to delegate the release to some of my colleages at
work that might have a few spare hours, but they don’t even have commit
access so that is not feasible.
See above; as long as hudson has commit access it would work. But they would need to sign up to seven Xircles of haus in order to kick out the Jira release notes.
Any suggestions on what we could do to improve the release process?
I am a big fan of trying the collaborate; and have a standing offer open to release GeoTools if someone needs to make a GeoServer or uDig release.
That does not however make good use of your colleagues. In a sense when the release process was in terrible shape it was easier to make use of volunteers for testing and QA.
The ideal-ideal situation would be something like a customized hudson build
that given the release notes and the branch name does it all, making the packages
available for upload to sourceforge and the like.
But any way to further shrink the release times would be welcomed
We could write a shell script for some stages of the release process (the staging of files to be zipped up and uploaded to source forge for example). We have done something similar for uDig now and it makes an amazing difference in how easy it is to make a release.
If we were really worried about cross platform we could make it an ant script.
Yeah I think a new hudson job on the build server could do all of this and automate pretty everything minus the announcements. Basically the input would simply be a release number and a revision. The job would tag, build, update version numbers, etc… It is definitely a fair bit of scripting work but certainly doable.
Which brings me to a related point, i would like to commit all the hudson scripts into svn… there is a lot of logic there and currently it is just sittin gon the build server unversioned.
The current situation, with the cite tests running every night, is certainly better
than it was once, but there is still a lot of work to do, and that work has to
be done by someone that has all the keys to the project administration areas.
In a perfect world the maven release target would work and take care of tagging etc. We could then place that in hudson and ask someone to poke the button (and make the JIRA release notes).
Sometimes I’d like to delegate the release to some of my colleages at
work that might have a few spare hours, but they don’t even have commit
access so that is not feasible.
See above; as long as hudson has commit access it would work. But they would need to sign up to seven Xircles of haus in order to kick out the Jira release notes.
Any suggestions on what we could do to improve the release process?
I am a big fan of trying the collaborate; and have a standing offer open to release GeoTools if someone needs to make a GeoServer or uDig release.
That does not however make good use of your colleagues. In a sense when the release process was in terrible shape it was easier to make use of volunteers for testing and QA.
The ideal-ideal situation would be something like a customized hudson build
that given the release notes and the branch name does it all, making the packages
available for upload to sourceforge and the like.
But any way to further shrink the release times would be welcomed
We could write a shell script for some stages of the release process (the staging of files to be zipped up and uploaded to source forge for example). We have done something similar for uDig now and it makes an amazing difference in how easy it is to make a release.
If we were really worried about cross platform we could make it an ant script.
Jody
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
Yeah I think a new hudson job on the build server could do all of this and automate pretty everything minus the announcements. Basically the input would simply be a release number and a revision. The job would tag, build, update version numbers, etc… It is definitely a fair bit of scripting work but certainly doable.
Which brings me to a related point, i would like to commit all the hudson scripts into svn… there is a lot of logic there and currently it is just sittin gon the build server unversioned.
src/
doc/
data/
buildserver/ <---- here?
In GeoTools we have a build directory that could be a fitting place too
Cheers
Andrea
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
+1 and yeah good idea. You would need to release in Jira and feed that number into the script as well (for the release notes).
–
Jody Garnett
On Saturday, 1 October 2011 at 2:50 AM, Justin Deoliveira wrote:
Yeah I think a new hudson job on the build server could do all of this and automate pretty everything minus the announcements. Basically the input would simply be a release number and a revision. The job would tag, build, update version numbers, etc… It is definitely a fair bit of scripting work but certainly doable.
Which brings me to a related point, i would like to commit all the hudson scripts into svn… there is a lot of logic there and currently it is just sittin gon the build server unversioned.
The current situation, with the cite tests running every night, is certainly better
than it was once, but there is still a lot of work to do, and that work has to
be done by someone that has all the keys to the project administration areas.
In a perfect world the maven release target would work and take care of tagging etc. We could then place that in hudson and ask someone to poke the button (and make the JIRA release notes).
Sometimes I’d like to delegate the release to some of my colleages at
work that might have a few spare hours, but they don’t even have commit
access so that is not feasible.
See above; as long as hudson has commit access it would work. But they would need to sign up to seven Xircles of haus in order to kick out the Jira release notes.
Any suggestions on what we could do to improve the release process?
I am a big fan of trying the collaborate; and have a standing offer open to release GeoTools if someone needs to make a GeoServer or uDig release.
That does not however make good use of your colleagues. In a sense when the release process was in terrible shape it was easier to make use of volunteers for testing and QA.
The ideal-ideal situation would be something like a customized hudson build
that given the release notes and the branch name does it all, making the packages
available for upload to sourceforge and the like.
But any way to further shrink the release times would be welcomed
We could write a shell script for some stages of the release process (the staging of files to be zipped up and uploaded to source forge for example). We have done something similar for uDig now and it makes an amazing difference in how easy it is to make a release.
If we were really worried about cross platform we could make it an ant script.
Jody
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2