Practicing Continuous Deployment: Insights from the Cruise (now GoCD) Project

In 2009 the author and Jez Humble began applying continuous delivery within their product team, initially naming the project "Cruise" (later open‑sourced as GoCD). The focus shifted from whether to adopt continuous integration to how to effectively perform it, especially addressing the "last mile"—the final step of getting software into production quickly and safely.

The "last mile" often takes days or weeks due to complex deployment environments, manual hand‑offs, and the high risk of production failures. To solve this, the team pursued continuous deployment, extending continuous integration across the entire software lifecycle.

Cruise’s architecture follows a Server/Agent model with distinct environments: a User Acceptance Testing (UAT) environment for internal CI/CD and a Production environment serving multiple customer projects. Although deployment scripts could be automated, a manual approval gate was kept between UAT and Production.

The deployment pipeline consists of several stages: dev (unit tests and static analysis), ft (functional integration tests with VCS), twist‑tests (functional tests written with Twist), dist (package generation), UAT (automatic deployment to the UAT environment), production (deployment to the shared production CI server), and publish (global release). The first three stages trigger automatically, while later stages require manual initiation.

Key practices for successful continuous deployment include:

Broad automated test coverage (unit, functional integration, acceptance, and performance tests) with feedback times under 15–30 minutes, aided by a custom test‑load‑balancer that distributes tests across agents.

Minimizing manual steps in the deployment process; most actions are automated, and agents auto‑update alongside the server.

Deploying early under controlled quality, using UAT as a gate before Production, and maintaining weekly Production releases.

Implementing risk‑mitigation measures such as deploying during low‑traffic periods, having technical staff on‑site, backing up data, and preparing rollback scripts.

These practices allowed the team to increase deployment frequency from days to multiple times per day, with deployment times under 15 minutes and only one minute of downtime, thereby reducing risk, accelerating feedback, and letting developers focus on building new features.

Overall, establishing an automated deployment pipeline proved highly beneficial, enabling faster, safer releases and supporting ThoughtWorks’ broader efforts to solve the "last mile" challenge for many projects.