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).

[caption id=“attachment_137” align=“alignleft” width=“128” caption=“Cruise Dashboard”][/caption]

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

“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”.

[caption id=“attachment_138” align=“alignleft” width=“128” caption=“Cruise Pipeline Activity”][/caption]

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: