Cruisecontrol enterprise best practices (1): publish with a publisher

Cruisecontrol enterprise best practices (1): publish with a publishercopyright 2007 Julian Simpson. All rights reserved.

Original article: cruisecontrol Enterprise: 10 Best Practices

I'm an infrastructure specialist at thoughtworks. in my role I make sure that we are building our software so it can successfully be deployed to production. in this series of blog posts I hope to pass on my top ten tips for using cruisecontrol enterprise quota tively. i'm writing these with the developers or systems administrators in mind: the people who most often manage cruisecontrol. however, I hope that anybody who is interested in continuous integration will get something from these articles.

#1: publish with a publisher: publish with publisher instead of Publishing during build

Many projects use the concept of "release": place the build product to a specified place, or send the test results to the end user. artifactspublisher is a very common method used to publish files to a repository in the format of cruisecontrol's own timestamp directory, so as to build logs, the product and test results can be displayed through the new cruisecontrol dashboard or the traditional cruisecontrol reporting application.

Artifactspublisher is a member of the entire publisher family, and my favorite is antpubliisher. if your ant build ends by releasing the building product to the repository or tag your version control system, you may need to do this in another way. consider the following example of ant script called by cruisecontrol:

<Project>
<Target name = "Dist" Description = "build everything">
</Target>
<Target name = "clean" Description = "delete all Build artifacts">
</Target>
<Target name = "test" Description = "Run unit tests">
</Target>
<Target name = "publish" Description = "Publish to repository">
</Target>

<Target name = "Cruise" depends = "clean, DIST, test, publish"/>
</Project>

The final step of building is to publish the work product that passes the unit test to a repository or similar place through the "publish" target. this is good for cruisecontrol, but the concept of "release" is not really suitable for developers to build. if we can break the connection between "release" and other parts of the build process, developers can use the same build process as cruisecontrol. to do this, you only need to have cruisecontrol call the build script you use during development, and use "publish" as an independent ant target:

<Project>
<Target name = "Dist" Description = "build everything">
</Target>
<Target name = "clean" Description = "delete all Build artifacts">
</Target>
<Target name = "test" Description = "Run unit tests">
</Target>

<Target name = "Dev" depends = "clean, DIST, test"/>

<Target name = "publish" Description = "Publish to repository" If = "logfile">
</Target>

</Project>

The 'if' attribute in 'Publish 'Target is used to ensure that this target will only be run by publisher or a specific person. Next, you only need to modify the configuration of cruisecontrol:

<! -- Some config removed from this example -->

<Schedule interval = "60">
<Ant antworkingdir = "$ {checkout. dir}" buildfile = "build. xml" target = "Dev"/>
</Schedule>

<Publishers>
<Onsuccess>
<Antpublisher antworkingdir = "$ {checkout. dir}" buildfile = "build. xml" target = "publish"/>
<Onsuccess>
</Publishers>

OK, this is done. once you apply new configurations, cruisecontrol runs the same ant build as the developer. this means that the building fails not because "cruisecontrol" has done anything mysterious. this also helps to shorten the build feedback cycle through faster reporting of success or failure. when developers celebrate or are depressed about building success or failure, antpublisher continues to do the work of releasing the building product to the network at the same time. I also use it to tag codebase. If the build is successful, this is part of "continuous integration.

Publishers can be directly used in the <publishers> element of the configuration file, so that after each build, no matter whether it succeeds or fails, it will run. you can also set conditional running in <onsuccess> or <onfailure>.

Publishers has a cousin named bootstrappers. I also want to talk about it later.

-----------------------------
I think the benefit of this practice is

1. Developers do not need to release each time they build on their own machines, saving time
2. Using the same build script as the developer, cruisecontrol reduces the probability that the building fails while the developer builds successfully, saving debugging time.
3. When cruisecontrol runs publisher, developers can continue to work, improving concurrency and saving time.