Cruise: The Next CI Framework?

I’ve been looking at Cruise, which is a continuous integration framework from ThoughtWorks recently. I have belly-ached in past posts about a need to get CI running for our Flex projects, an undone task that slaps me around daily, reminding me of my folly and hypocrisy. The issue with Flex and CI is that it seems to be relatively new ground.   Sure, some folks are doing it (almost all using Hudson) but there aren’t a lot of them. And they are all java people so they are comfy-cozy in the Hudson-Maven-jar land.   I am a measly .NET person that pulls my knees to my chest and hides my face from their nerdy superiority.
I read a couple of posts on Cruise, and decided to give it a go.   It is free for a two-agent (more on agents in a bit) install. I’ve no idea what the cost is after that, but I’ve asked TW.   Cruise consist of 2 or more parts. Part one is a server. It’s a one-click install (I am using Windows) and it creates a service called Cruise Server. Parts two or more are agents, also a one-click install, and also creates a service called Cruise Agent.   The idea behind agents is to create a “build grid”, using agents to distribute the load of building and testing your code.   You can make an agent out of any box (Win, Mac, Linux) which also allows testing of the code in different environments.   Scalability and multiple environments puts Cruise ahead of any CI framework I’ve used (CC.NET is the only one).  Very cool.

Cruise’s over-arching approach to CI is the pipeline. You create a pipeline, which seems to often be an atomic project.    A pipeline has one or more stages, which are things like Build, Test, Deploy to UA, etc. To be clear, the stages are defined by you, so there isn’t a finite list of what the stages can be.   In essence, a stage is a container of one or more jobs.  Jobs are where the rubber hits the road.   A job is a discrete bit of execution. A job can use one of ant, nant, rake, or exec, so anything with a command line interface, basically.  Therein lies the simplicity of Cruise.  It allows the build and test tools to handle the building and testing,  while it handles the scaling and pipeline.
One of the items provided by Cruise Server is a dashboard, which is very simple (see screen shot).

Cruise Dashboard

Cruise Dashboard

As you might expect, you can start a pipeline, or a stage of a pipeline.   You can look at the current activity or administer your CI server.  The administration of Cruise is based on a simple XML schema ( I know, I know, XML…but it’s not “bad” XML)  The initial setup of an item (pipeline, stage, job, agent, etc) can be point-and-click driven, but any changes after that are editing the XML.  You can do it right in place and Cruise picks up the changes on-the-fly.   In my testing I made a pipeline that had a Test stage feeding into a Build stage.  I wanted to switch them around, so I just cut the XML element and pasted it back into the pipeline where I wanted it to run, and it was done.  Very easy.  I like easy.

Creating a pipeline requires two pieces of infomation: The type of builder (ant, nant, rake, exec) and the location and type of your source control.    It supports Git, Mercurial, Perforce, and Subversion out of the box.  With your pipeline created, you can add stages using

<stage name="Build"></stage>

“Build” above is the name I chose, so it coudl be anything.  Then you add jobs to the stage in a similar manner.  For an ant builder, you would specify the build file and target.    Also, jobs can have artifacts, so if you have a task that generates documentation, Cruise will upload it to the server.  A better example might be unit test reports that are generated by your testing framework.  Just tell Cruise where they are,  and it will upload them to the server.  You can, in fact, create a tab on the job output that will show the test reports (it’s an iframe, nothing fancy) with very little configuration.

You can look at a pipeline in a couple of different ways, the coolest is the “Pipeline Activity”.

Cruise Pipeline Activity

Cruise Pipeline Activity

You can visit or rerun any of the past stages my clicking on them.  Also, you can define manual transitions, which you would kick off from this interface.  An example of when you might want a manual transition is a deployment to UAT, which you wouldn’t do on every build (would you?)

In my initial testing, I wanted to get a Flex build going in Cruise with automated tests using Fluint.  The lion share of the work was defining the ant script.   Flex and Fluint have ant tasks already, so building the ant script was relatively simple.  I defined a stage called “Build” with a ant buld job and a stage called “Test” with a single artifact (my test report) and ant build job.  This gave me a functioning CI Server that builds on each check in to SVN and runs all the Fluint tests, then uploads the test reports so I can see them on the build output.  Here is the XML for that:

<pipeline name="FlexBuildTest">
    <svn url="http://svnserver/svn/svnRepo1/trunk" username="svnuser" password="svnpwed" />
  <stage name="Build">
      <job name="AntBuild">
          <ant buildfile="build.xml" />
  <stage name="Test">
      <job name="AntTestBuild">
          <test src="deploy/reports" dest="test-reports" />
          <ant buildfile="build.xml" target="test" />
I am pretty impressed so far.  We are just about to set up our build environment for a new project, and I plan on using Cruise.  We can use it for our Flex and .NET stuff, which is a bonus.  It’s simple to setup and maintain.  I’ll try to come back and blog about any other issues/cool things we find.
Meanwhile, head over to ThoughtWorks and check it out.  They have regularly scheduled webcasts to demo Cruise (I saw one today) so you can get a better idea of how Cruise functions.
Reblog this post [with Zemanta]

About Ruprict

I am a nerd that is a Nerd Wannabe. I have more kids than should be allowed by law, a lovely wife, and a different sense of humor than most. I work in the field of GIS, where I am still trying to find myself on the map. View all posts by Ruprict

4 responses to “Cruise: The Next CI Framework?

  • Piotr

    Do you know any way to limit svn checouts in cruise for one pipeline?
    I mean when I have stage build and test it is doing svn checkout twice!
    Where it should be done only at 1st stage.

    Good Blog anyway.

  • ruprict

    We actually moved to Hudson once we found out the cost for Cruise (can’t remember what it was, but it was a LOT) so I am little help here. However, the behavior you describe is odd. Cruise should check svn at the beginning of a pipeline and then not again during the stages of that pipeline.

    Have you sent the question to Thoughtworks? I have found them very responsive.

    Sorry I am not much help.

  • Nav4Nav

    Modification check failed for material: svn://dev/**/trunk
    Error happens when Executing: svn log –non-interactive –xml -v –limit 1 svn://dev/***/trunk Make sure this command can execute manually.
    Did’t get this error
    Does Cruise support tortoise svn?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: