Continuous Deployment in 5 Easy Steps

Our goal as a team is to work as fast as we can reliably produce high-quality code – and no faster. Going any "faster" is actually just creating delayed waste that will slow us down later.

make it impossible to do a deployment for a given revision if the CI server hasn't yet run and had all tests pass for that revision.

But its role in continuous deployment is much more important. This is the place you can control what I like to call "the production line" to borrow a metaphor from manufacturing. When something is going wrong with our systems at any place along the line, this script should halt new commits. So if the CI server runs a build and even one test breaks, the commit script should prohibit new code from being added to the repository. In subsequent steps, we'll add additional rules that also "stop the line," and therefore halt new commits.

Continuous integration server. This is the backbone of continuous deployment. We need a centralized place where all automated tests (unit tests, functional tests, integration tests, everything) can be run and monitored upon every commit. There are many fine free software tools to make this easy – I have had success with BuildBot. Whatever tool you use, it's important that it be able to run all the tests your organization writes, in all languages and frameworks.

It's a process whereby all code that is written for an application is immediately deployed into production. The result is a dramatic lowering of cycle time and freeing up of individual initiative. It has enabled companies I've worked with to deploy new code to production as often as fifty times every day.

one simple rule: we'll add a new automated test every time we fix a bug. Following that rule will start to immediately get testing where it's needed most: in the parts of your code that have the most bugs and, therefore, drive the most waste for your developers. Even better, these tests will start to pay immediate dividends by propping up that most-unstable code and freeing up a lot of time that used to be devoted to finding and fixing regressions (aka "firefighting").

On the contrary, I believe that continuous deployment requires tremendous discipline and can greatly enhance software quality, by applying a rigorous set of standards to every change to prevent regressions, outages, or harm to key business metrics.