Archive: ‘Cruise Control’ Category

Comparing TWO continuous build tools: Cruise Control and Hudson

9 comments May 10th, 2008

Continuum, Cruise Control and Hudson are some of the famous continuous integration tools which people are using nowadays. Cruise Control is the pioneer one and people are using from a long period of time. Continuum is from the Maven team and very high integration with Maven 1 and 2. Hudson is the new one but it is more popular now.

In our department my PM asked me and to my friend, to do the Cruise Control + SVN +Maven based continuous build mechanism. During this process I had gone through some more R&D on the tools which are available for the continuous build process. In that process I found some of the comments about Hudson. Those were very interesting.. So I thought of comparing this with our Cruise control.

Here in this post I am trying to compare Hudson and Cruise Control. The basic TEN points or features listed below are taken from Hudson’s official site and I am just trying to compare these all with the capabilities of cruise Control. I had tried to add my own experience with these. Correct me if there is any features that were wrongly entered or any new features that you know about these.

Versions and platform:

Hudson            : 1.213

Cruise Control : 2.7.1

Plat form         : Windows

 

images Hudson

 

banner Cruise Control

1 Open Source     1 Open Source
2 Easy installation: Just java -jar Hudson.war, or deploy it in a servlet container. No additional install, no database.

2.

It also gives us very easy installation. Just unzip the downloaded zip file. That’s it. It is actually using an internal Jetty server. No Database, no install here also.
3 Easy configuration: Hudson can be configured entirely from its friendly web GUI with extensive on-the-fly error checks and inline help. There’s no need to tweak XML manually anymore, although if you’d like to do so, you can do that, too.

3.

Big difference comes here. The GUI providing by Cruise control for configuration is not at all good. It just displays the config.xml file. :( Its no way near to Hudson for Configuration GUI part. If you want to configure Cruise Control then you must study about the structure of the Config.xml first.
4 Change set support: Hudson can generate a list of changes made into the build from CVS/Subversion. This is also done in a fairly efficient fashion, to reduce the load of the repository.

4.

Cruise control also show the list of files which are changes at this check-in process.
5 Permanent links: Hudson gives you clean readable URLs for most of its pages, including some permanent links link “latest build”/”latest successful build”, so that they can be easily linked from elsewhere.

5.

Uhm… Cruise control is not giving this. It gives a link with some log code number attached with it. Its looking horrible and cant be easily likable.
6 RSS/E-mail/IM Integration: Monitor build results by RSS or e-mail to get real-time notifications on failures.

6.

It also gives RSS and email functionality. Don’t know about IM support. If we need to change the Email structure then either we have to change XSL or CSS file which we are using  in the email config.
7 After-the-fact tagging: Builds can be tagged long after builds are completed

7.

N.A.
8 Detect new failing tests while build     8 Failing tests will show in the dashboard. But no separation between new and old.
9 Notify when first test in build fails     9 No such type of notification.
10 JUnit/TestNG test reporting: JUnit test reports can be tabulated, summarized, and displayed with history information, such as when it started breaking, etc. History trend is plotted into a graph.

10

It is showing all the unit test results but not as good as Hudson does. There is no detailed information like when it started breaking, History etc. and no graph for unit results too.
11 Distributed builds: Hudson can distribute build/test loads to multiple computers. This lets you get the most out of those idle workstations sitting beneath developers’ desks.

11.

The build distribution is done through the maven install goal. Its
12 File fingerprinting: Hudson can keep track of which build produced which jars, and which build is using which version of jars, and so on. This works even for jars that are produced outside Hudson, and is ideal for projects to track dependency.

12.

No idea.
13 Plugin Support: Hudson can be extended via 3rd party plug-ins. You can write plug-ins to make Hudson support tools/processes that your team uses.

13.

Plug-ins are there in Cruise control also.
14 Dash board: Hudson has an attractive dashboard with Colorful as well as meaningful icons. We can separate this building projects into subgroups also. It will also shows building projects. Well designed Ajax pages.

14.

It gives an attractive Dash board. It displays all the necessary information which we need to know. We can directly build from there also. Viewing/ downloading the log file is also allowed from this Interface.
15 Local Copy of projects: Handled by Hudson itself. No need to do by the user.

15.

Maintaining a local copy with the exact SVN data makes us more uncomfortable. The user has to copy the Project into the local folder with SVN data.
16 Auto copy of SVN updates: No need to provide any other code to copy the project from SVN to the local compiling folder.

16.

Its not copying the data from the SVN directly. We need to write (In our case we wrote an ANT build file to download the latest copy of Project from SVN) something separate.
17 Running In background: If the server where we deployed the war is running then its okay for Hudson.

17.

If we want to run it without console then we need to make it a separate ‘WINDOWS Service’ using any third party tool.
18 We can deploy the war file in any of the server we wanted.

18.

Jetty server is using internally.
19 User authorization schemes. more configurable.

19.

User authentication is there but no schemes at all.
20 Very Active mailing list.

20.

From a long period people are using this. So it gives so many search results. But its mailing list is not that much active when compared with Hudson.

Alternative building tools available.

I got this list from ThoughtWorks. HERE we will get a good comparison of these all.

Conclusion:

In my opinion Hudson much more better than Cruise Control. The time we will take to start to use Cruise control will be high when we compared with Hudson. The GUI which makes all the Configurations very very easy. The Ajax support makes the configuration more “Error Free”. Though Cruise control is using by a lot of people, when we looked into the features, mailing list, the fastness and support from Developers I think Hudson will be a good option.

Related links : Continuous Integration with Hudson: A Presentation and an Interview podcast

Book Mark it-> del.icio.us | Reddit | Slashdot | Digg | Facebook | Technorati | Google | StumbleUpon | Window Live | Tailrank | Furl | Netscape | Yahoo | BlinkList

Popularity: 100% [?]

Bookmark this on BuzzURLBookmark this on BuzzURL Post to TwitterTweets for this web page Bookmark this on FC2 Bookmark newsing it! Choix it! Add to Google Bookmark Bookmark this on Delicious Digg This

Configuring "Cruise Control" with "Maven2" and "Subversion 1.4.6" for continuous build environment

No comments April 29th, 2008

Continous Integration build system is very useful in a software development company where members of a team integrate their work frequently. It reduces the wastage of time and at the same time it helps us to maintain all the builds up to date. Previous week we also configured a continous build flow in our R&D division using Cruise Control, Maven and Subversion.  For this what we did is, we  created our project module builds in MAVEN2 (Using the latest technology which gives us more options and easiness to handle projects). Created a new SVN environment and Configured the SVN with Cruise Control.

Here In this post I am describing about the Configuration of Cruise control with Maven and Subversion.

Versions Used:

Subversion : 1.4.6

Maven  : 2.0

Cruise Control : 2.7.2

What is Cruise Control?

CruiseControl is a popular open source tool for implementing Continuous Integration (CI) of Java applications. The idea behind CI is; Build, regression test, and deploy your software application to a test environment every time a code change is committed to version control. If the code change causes the build to break, the regression test to fail, or a problem with the deployment, identify and correct the problem promptly. CruiseControl is ideally suited for CI. It is a reliable tool that provides real value to Java development teams of any size.

What is Continuous Integration?

Continuous Integration is a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

What is the goal which we want to acheive from this process?

Using maven we are maintaining a Center repository for the JARs and trying to avoid the famous Java programers error word.. “Its working in my machine but I dont know why its not in yours”. Maven will give an Object oriented way to our build system and will give a lot of plugins to make it more advanced and useful.

The cruise control will build automatically when we update any new code to the SVN and will send emails to the respective persons about the build’s  success or failures. It will give the name of the programmer who is checked in the code to SVN and also the files where the code is failing.

1. Installing and running Cruise Control

Step 1:

Download the latest version of Cruise Control from the following link. http://cruisecontrol.sourceforge.net/download.html

Step 2:

Extract the files in to a specific location where you want to install the CruiseControl. For Example: C:\CruiseControl2.7.9

Step 3:

In the Cruise control installation directory we have a batch file called cruisecontrol.bat. Double click on this will start the cruise control in port 8080. Internally a jetty Server is running… We can change the port by editing the batch file.

2. Configuring Cruise Control for Maven2 and Subversion1.4.6.

Prerequisites:

  1. Apache Maven2 should be installed in the server where we are installing and configuring CruiseControl
  2. Subversion should be installed and running on the server.

Follow the two Steps below to configure a new project in Cruise control.

  1. Configuring in config.xml file.

This is the main part of configuring a project in the cruise control. Here we are giving the necessaey informations about the project, the Scheduling the time, configuring the bootstrappers, giving the location of the local copy, Giving the SVN location, specifing the MAVEN or ANT commands which we have to run in scheduled time etc. Please find the comments written in each part for more information.

Here in this I had configured all the common parameters at the TOP of the config.xml for reusability.

<! — Project Configurations –>

<property name=”log.dir” value=”./logs/${project.name}”/>

<property name=”projects.dir” value=”./projects”/>

<property name=”projects.checkout.dir” value=”${projects.dir}”/>

<property name=”project.log.dir” value=”${projects.dir}/logs/${project.name}”/>

<! — Repository configurations for that project — >

<property name=”svn.repository” value=”< Repository URL>“/>

<property name=”svn.portal.project” value=”${svn.repository}/<Project name Here>“/>

<property name=”svn.user” value=”<username here>“/>

<property name=”svn.password” value=”<password here>“/>

<! — Build Specific Configurations –>

<property name=”maven.home” value=”E:\Apache\apache-maven-2.0.8″/>

<property name=”ant.home” value=”E:\cruisecontrol-bin-2.7.1\apache-ant-1.7.0″/>

<! — Cruise Control – Scheduler Specific Configurations–>

<property name=”schedule.interval” value=”600″/>

<property name=”quiet.period” value=”300″/>

<! — Mail configurations –>

<property name=”buildresults.url” value=”http://localhost:8080/buildresults/${project.name}”/>

<property name=”css.location” value=”E:\cruisecontrol-bin-2.7.1\docs\cruisecontrol.css”/>

<property name=”xsl.dir” value=”E:\cruisecontrol-bin-2.7.1\webapps\cruisecontrol\xsl”/>

<property name=”mail.host” value=”<mail server name>“/>

<property name=”build.url” value=”<The url where Cruise control is running>“/>

<property name=”mail.subject.prefix” value=”[Cruise Control] Project [${project.name}]“/>

<property name=”cc.mail.username” value=”<mail username here>“/>

<property name=”cc.mail.password” value=”< mail password here>“/>

<property name=”return.name” value=”Cruise Control Agent”/>

<! — Always send addresses –>

<property name=”mail.address.buildmanager” value=”<mail address here>“/>

<! — Failure addresses –>

<property name=”mail.address.ifFails” value=”<mail address here>“/>

<! — Success addresses –>

<property name=”mail.address.ifSuccess” value=”<mail address here>“/>

<! — Return Address –>

<property name=”mail.address.return” value=”<mail address here>“/>

<! — Starting the Project Specific information –>

<project name=”<Give project name here>“>

<! —Specifying the cruise control plug-ins information [It’s optional] –>

<plugin name=”svn” lassname=”net.sourceforge.cruisecontrol.sourcecontrols.SVN”/>

<plugin name=”svnbootstrapper” classname=”net.sourceforge.cruisecontrol.bootstrappers.SVNBootstrapper”/>

<! — This writes a build status snippet to the file system. –>

<listeners>

<currentbuildstatuslistener file=”logs/${project.name}/status.txt”/>

</listeners>

<! — This bootstraps resources from Subversion. –>

<bootstrappers>

<svnbootstrapper LocalWorkingCopy=”projects/${project.name}” />

<bootstrappers>

<! — A container element for a set of modifications collected from all included SourceControl elements.<modificationset> can contain multiple elements which can be useful to check only parts of a large Project rather than checking all files every time. –>

<modificationset quietperiod=”${quiet.period}”>

<svn Localworkingcopy=”projects/${project.name}” RepositoryLocation=”${svn.portal. project}”

useLocalRevision=”true”/>

<maven2snapshotdependency pomfile=”projects/${project.name}/pom.xml” user=”<SVN username here>“/>

</modificationset>

<! — This is the main part. Here the first ant task will copy the current data from the SVN to the local project folder.

The second task is doing scm update, clean and install goals of maven–>

<schedule interval=”${schedule.interval}”>

<composite>

<ant anthome=”${ant.home}” buildfile=”projects/${project.name}/cc-build.xml[l1] ” />

<maven2 mvnhome=”${maven.home}” pomfile=”projects/${project.name}/pom.xml” goal=”clean install site:site site:deploy”/>

</composite>

</schedule>

<! — In this part we are configuring the mail related information. To whom we need to send mails, what structure etc… etc –>

<publishers>

<onsuccess>

<artifactspublisher dest=”artifacts/${project.name}” file=”projects/${project.name}/target/${project.name}.jar”/>

</onsuccess>

<htmlemail mailhost=”${mail.host}” subjectprefix=”${mail.subject.prefix}” returnaddress=”${mail.address.return}”

buildresultsurl=”${build.url}/${project.name}” css=”${css.location}” xsldir=”${xsl.dir}”

xslfilelist=”header.xsl,buildresults.xsl” returnname=”${return.name}” skipusers=”false” spamwhilebroken=”false”

username=”${cc.mail.username}” password=”${cc.mail.password}” >

<always address=”${mail.address.buildmanager}”/>

</htmlemail>

</publishers>

</project>

Main points to note:

1. Schedule Time Interval : This is the time period in which cruise control is checking the SVN for updation.

2. ANT script in schedule composite tag: Which is used to copy the SVN updated files.

3. MAVEN goals: mvn clean compile site:site site:deploy This we used to clean and compile the code. Then it will create the site related files for that project and deploy it in a server which we specified in that POM file

If you have to configure more options please refer this link: http://cruisecontrol.sourceforge.net/main/configxml.html#modificationset

2. Create a local copy of the project in the Projects folder of the Cruise Control. Follow the following steps for that.

  • Copy the entire project folder from our eclipse workspace in to the “Projects” folder.
  • Make sure that that copy contains the correct SVN information also.
  • Create a ANT build file with the following information and store it in Projects> [Current Project folder]

Name it as cc-build.xml as we mentioned in the config.xml of Cruise oontrol.

<project name=”Project” default=”update-src” basedir=”.” >

<property name=”base.dir” value=”.” />

<target name=”update-src”>

<echo>Updating source from Subversion</echo>

<exec executable=”svn” dir=”${base.dir}”>

<arg line=”up” />

</exec>

</target>

</project>


[l1]This is the ANT script which is copying all the SVN updated data in to the Local copy. So we need to copy that ANT build file in to the Local projects folder.

Book Mark it-> del.icio.us | Reddit | Slashdot | Digg | Facebook | Technorati | Google | StumbleUpon | Window Live | Tailrank | Furl | Netscape | Yahoo | BlinkList

Popularity: 3% [?]

Bookmark this on BuzzURLBookmark this on BuzzURL Post to TwitterTweets for this web page Bookmark this on FC2 Bookmark newsing it! Choix it! Add to Google Bookmark Bookmark this on Delicious Digg This