Deployment Pipelines: Modeling your Build, Deployment, Test and Release Process

The idea behind deployment pipelines is simple. You have a build, deploy, test and release process that consists of a number of steps. You might start by compiling your code, then running automated unit and functional tests, followed by a number of manual testing steps that culminate in putting your application into staging and then production. However without dedicated tool support, it is hard to for your team to work out exactly what version of the software has been through which stages in the process, and what the results of the each step were. Actually getting the right version of the software deployed into the relevant testing environment reliably and in a timely manner so that feedback gets to the developers before it is out of date can be a significant challenge. And that's before you get to trying to actually release software.

Cruise won't fix this problem by itself. First of all you need to automate your build, test and deployment process. But once you do that, Cruise will hook everything up together so that your team can see exactly which check-ins have been through which stages of your release process and what the results were. Your QAs can self-serve builds into their environments. Your operations team can easily find the version of the software they want to deploy into staging or production and self-serve the deployment, and use Cruise 1.1's new re-run stage functionality to re-deploy the previous version if there is a problem with the latest and greatest.

Cruise also makes it easy to parallelize your build so that you can run a particular stage of your process on several boxes at once and roll up the results. There are several reasons you might want to do this: to split long-running tests into parallel suites, to run your automated tests on multiple platforms, or to deploy to a multi-server environment. Either way, Cruise's zero-configuration build cloud makes all these tasks simple so that you can focus on delivering value, not messing around with build plumbing.

Once you've installed Cruise, you will be presented with the add pipeline wizard which will help you set up your very first automated job. Just tell Cruise the name of your project (this will be used as the pipeline name), your revision control system details, and what task to perform, and Cruise will take care of the rest, including checking out your code for you. Optionally you can tell Cruise which artifacts (reports, binaries and so on) generated by your build you want uploaded for later use by the team.

The first job you create will probably be to compile your code (if you're using a compiled language) and run your automated unit test suite. Once this is done, you have a wealth of options. Before we dive into them, here's a diagram that explains how the pipeline metaphor works.

Pipelines, stages, jobs and approvals explained

With the pipeline you have two options -- add more stages, or add more jobs to the stages you already have. Which you do will depend on your particular process. But in general the rule should be: if you can parallelize, you should. This is because you'll get feedback more quickly with a highly parallelized pipeline. For example in the diagram above the compile and unit test job shares a stage with the static analysis (emma) job. You could also add jobs to your first stage to create a test database, or create some other artifact that will be used by your test and release process. Logically these jobs could all be thought of as independent steps -- but since you can parallelize them, you should. This should be your litmus test. Note also that it is good practice to have a first stage that runs in around ten minutes, so your developers get fast, high-level feedback as to whether their changes broke the application.

A typical second stage might run more long-running automated functional tests. You might create multiple jobs in this stage so you can split up your test suites and run them in parallel to speed them up, or because you want to run your tests on multiple environments (as in the example above).

Your later stages will typically contain jobs that deploy your application to manual testing environments such as your UAT, performance testing, staging, and even production environments. You might have a single job in each stage that deploys your application to the relevant server. If your environments require several servers to run, perhaps because you require separate boxes for your n-tier architecture, you might have a job for each server you need to deploy part of your application to. Each job would run on the box that needs deploying to, and pick up the relevant artifacts (created in the first stage) to deploy to that box.

If you were to create a pipeline in Cruise suggested in the diagram above, what you would actually see in Cruise's pipeline activity page would look a bit like this:

An example pipeline.

This pipeline activity view, which you can get to by clicking on the title of the pipeline on Cruise's dashboard, gives you an overview of the state of your application. On this view you can't see the individual jobs that make up your stages, but instead just the rolled-up results: green if all the jobs in the relevant stage passed, red if any of them failed. Along the top are the stages in your pipeline; down the side are the check-ins (if there are several check-ins while the first stage is building, they'll be grouped together for the next build of the pipeline, so it's not necessarily the case that every check in will lead to its own individual pipeline).

What you can see is that build 1.0.1 passed the "dev" stage (which ran the unit tests and did static analysis), and then also passed the ft stage (which ran the functional tests on Windows and Linux). The next (UAT) stage was not triggered, because it requires manual approval for this stage to be triggered.

build 1.0.2 also passed the dev and ft stage, and the user "cturner" pressed the approval button that deployed that revision into the UAT environment. Build 1.0.3 passed the dev stage but failed the functional tests, and build 1.0.4 didn't even pass the unit tests. But build 1.0.5 passed both the unit and functional tests, and is ready to be deployed into UAT by anyone who is authorized to press the "manual" approval button (in Cruise 1.1 you can lock down who is able to press these buttons).

From this page it is easy to see which versions of the software have been through which stages of your build, deploy, test and release process, and what the results of each stage were for each build. Furthermore, testers can use this page to self-serve deployments into their environments. If they deployed build 1.0.5 and found it to be buggy, they could re-deploy build 1.0.2 using the re-run stage function (new in Cruise 1.1). Cruise would then automatically update the sandbox on the agents running the jobs in this stage to the correct revision of version control and run the jobs in question.

So there you have it: visibility into and control over your application's lifecycle for your whole team, who can get the feedback they need in a snap, even if they're working on different timezones across the world.