The unit of work in Cruise is called a job . A job is a set of one or more tasks that can be performed on a single agent in your cloud. You can specify the resources a job needs to work properly, and Cruise will ensure the job only gets executed on an agent with the appropriate resources available. You can specify one or more resources an agent has available to it. These are simple text tags - Cruise Agent does not automatically determine anything about its environment.

Jobs are grouped into stages. A stage is a collection of jobs that can be executed in parallel. This is the mechanism that allows you to, for example, split test suites into multiple parallel streams, run the same build on multiple platforms simultaneously etc. A stage passes only when all the jobs in the stage pass.

An approval can be defined for each stage at the beginning of the stage. Stage approvals can be of two types – success and manual and if no stage approval is defined success is the default condition to trigger the next stage. Manual approval requires user intervention to trigger the stage. For manual approvals authorized users or user roles can be defined to designate particular users or user groups that can trigger stages.

Finally, stages are joined sequentially to form a pipeline . The first stage in a pipeline can be triggered by a change in version control, forcing the pipeline to become active, or by a dependency on a given stage of another pipeline. When a given stage completes successfully, it will by default trigger the next stage in the pipeline to build. Alternatively you can require manual approval for a stage to be triggered. If a manual approval is defined at the beginning of a pipeline the scheduler waits for the manual approval even to trigger the pipeline. Security on approvals at the beginning of pipelines can be used effectively to make pipelines "read only" for unauthorized users.

So what does a pipeline look like? Here's an example:

The first stage has two jobs. The unit test job compiles the code and runs the unit tests. The compiled code is then uploaded to the artifacts repository. This is the one and only time the code is compiled -- and of course if you're using an interpreted language you can skip this step. The second job does static analysis of the code, uploading the results as html test reports and build properties for further analysis.

When the first stage passes, it automatically triggers the functional test stage. The jobs in this stage download that binaries from the artifacts repository, and run a series of functional tests. One job runs on a Linux box, the other on Windows. If your tests take a long time to run, you could split them into suites and run these as multiple jobs in parallel.

Finally there is a stage which deploys your software into your UAT environment for manual testing. This stage has a manual approval in front of it, meaning that somebody has to click a button in order to deploy the application into UAT. Running this stage proves out your automated deployment process -- and it should include some smoke tests that make the job fail if the deployment doesn't work.

The pipeline metaphor gives you several important benefits:

• Because of the way pipelines are modeled and presented, it is trivially easy to match up an acceptance test failure, or a flaw in the UAT environment, with the version of the code that caused it.
• Because you only compile once, you ensure that the thing you are testing is the same thing you will release, and you don't waste resources compiling repeatedly.
• Finally, Cruise allows you to build manual steps into your testing process so that your QAs and users can manually test your software.