A few years ago I joined Bugaboo, makers of some of the best baby strollers (or prams) in the world, as the manager of software development for their eCommerce platform.

At the time, they were already over-schedule and over-budget on a re-platforming project. One of the things I was able to do to help get the project back on schedule was implement what I now refer to as Lean Continuous Deployment: the idea that we can deploy every change as soon as the developer hits the Merge button, even without automated testing.

Bugaboo’s core web site was effectively a monolithic CMS system written in Java. When I joined, there were no automated tests, except for a few sparse unit tests for a few backend components. We did have a group of several manual QA testers, though.

A core concept of the Lean CD approach is to continue doing any existing manual checks, such as QA, but to do them before the developer presses the Merge button.

At Bugaboo, we accomplished this by scripting the creation of an automatic test environment on AWS for every pull request in Git. Every new pull request fired up a new environment. This environment could be used for manual QA, or any other manual testing or preview. When that pull request was merged or closed, the environment was deleted.

For an application that size, it did take 15 to 20 minutes to start the new environment. But it had a revolutionary impact on the development process:

• QA engineers were able to test each new feature in isolation, rather than all muddled together in a single staging environment.
• Developers knew that their feature was done when they pressed Merge. There was no lingering question about whether it would pass QA and need more work later, or if it might even have to be reverted before release.
• Developers could demo their individual features during Sprint Reviews, or ad-hoc, without fear that some other developer’s experimental feature might break things.