Automated Releases with Hudson+Ant+Subversion_问答_开发者

We have recently spun up Hudson for continuous integration, and beginning to enjoy the benefits of automated test, static analysis, etc. Our next step is to get our cumbersome manual release process underway. What I envision is a two-phase process:

Branch for a release line. Once our development line stabilizes, we'd like to branch. Because we have low-density, high-demand users, there is often a little flurry of activity following a formal release, resulting in a bit of stop-and-go-development at the beginning of a release line (and we don't want to block mainline development for this) so the practice of branching at a convenient time, and then allowing for a stabilization window (hours to a day or two) makes sense. (This is done in subversion; usually we tag the development release immediately before the branch, then branch, then carry on parallel development)
Cut a release from the branch. This currently involves
1. A bit of "fixup" to put release numbers where they belong.
2. Checkin
3. Tag
4. Export
5. Build
6. A bit of "fixup" to return release numbers to "devel/snapshot".
7. Checkin

So to operationalize something like this in Hudson, cleanly, how can we:

Execute a branch operation from Hudson that branches the tree, given a new release branch name, and spawns a new Hudson job to create a new continuous build line for that branch. (It's close to a copy of the existing -trunk configuration, but have to replace some workspace names and things...)
Where does the logic belong to interact with Subversion? (Conceivably, could be in the ant script; could be a separate script; Hudson/plugins also seem to provide some of this logic?)
Any thoughts on users/permissions for Hudson/subsidiary processes when it talks to the repo in write mode?
How about phase two, the above questions also apply, can I just use the release plugin to automate logic like this?

I have perused the Hudson and Release Plugin documentation, but it's rather spotty and there aren't a lot of worked examples laid out from end-to-end...

Edited to add: I understand and expected the "Have you considered Maven?" responses... I appreciate it, and I understand that Maven is probably the right long-term solution, but a build-system changeove开发者_运维问答r along with all the sturm and drang of moving to Maven's precise constraints and educating the technical staff isn't feasible in the near-term. Presumably there's a way to do this with Ant and a little elbow grease...

Short term Ant based process

Given your commitment to the Ant build process (and there's nothing wrong with that except for the goodies you're missing out on) I'd suggest that you mirror the Maven approach, but do it within Ant. So have a thorough read of this article that shows how to use SVNAnt.

Ideal solution for long term

As @Peter Lawray has mentioned, Maven is your friend here. Specifically look at the release plugin which will manage the process of tagging your Subversion repository with the "gold release" version of your project. Essentially, you perform a full build (including functional tests if you've got 'em) to verify your artifact, then Maven tags your Subversion repo and finally it runs over your project pom.xml files and re-versions them to the next level up (as snapshots).

In terms of a build process, Hudson works merrily with Maven and will build and test the artifacts (your JARs, WARs, EARs etc) in the sequence you specify in the Maven pom.xml.

You can tie in SeleniumRC and provide a multi-browser automated functional test environment as well if you wish. Maven handles it all from the build, to the deployment of the artifact into the build server then the subsequent functional testing with a final sign off by a release process.

I've blogged a little about this if you're interested.

This is intended as a solution until you have maven in place.

I think you should just create some scripts to do all the work (either ant and/or batch/shell scripts). Have a look at the Batch Task plugin. This allows you to run the release over the current workspace of your job. Your script(s) are intended to do all the work. You can set up a copy of your current job using the remote api. If the environment variables, like JobName, are not available, you would probably need to hardcode the job name (or record them during the build in an file on the workspace). At the end you will have an updated trunk (dev line), a new release line (in branches) and a job that runs all your CI on the release branch.

I wouldn't do the branching and tagging as part of the build, i'd do it by hand. This is (again!) perhaps a philosophical difference: i see Hudson as a way to take the current state of some code line and produce its artifacts, rather than as a tool for manipulating code lines. It's like a big compiler, but not like an IDE.

So, my process would look like (and our process, in fact, does look like):

Tag at the release point (call it root_release23_20101124)
Branch at that point (call it release23_20101124)
Edit the release properties files to add the release number, and do any other fixup
Check in to the branch
Set up a new Hudson job (by copying a template job) to build a release, configuring it to check out from the branch
Run the job

So, setting up a new release is a developer/build manager task, but actually building the release is done by Hudson.

Setting up a release does involve manual work, but you can't call it cumbersome - how long does it take to tag, branch, edit a few files, commit, create a job, and change its branch name?