Iâ€™ve mentioned this before, but like to do it again because I think these guys are awesome. If you have not listened to devopscafeâ€™s podcasts, this might be the right time to take a look at it. Here is a video of one of their sessions with folks at KaChing who have been doing amazing stuff around continuous deployments.
If you have read this blog before, you know how much I admire those who use continuous deployments in production. Doing that at scale is even more impressive. But the message which gets lost sometimes is that Continuous deployments may not be for everyone.
Most continuous integration environments usually do all of their deployments from trunk. Which means every check-in has to be production quality. Diggâ€™s Andrew Bayer gives a good explanation of how they do code reviews and pre-code check-ins before code is merged into trunk.
Site uptime and reliability depends on a comprehensive QA process to protect against unintentional mistakes. And for rapid deployments one has to abandon manual QA processes in favor of 100% automated testing with the goal of getting close to 100% code coverage. Thats hard if the code is not written in a way which can be tested easily.
But, unit and integration tests alone cannot guarantee quality. In addition to testing code which has been implemented in the application, there needs to be tests to look for things which shouldnâ€™t be implemented. For example, it would be nice to have tests to look for non-parameterized SQL calls in parts of code where it shouldnâ€™t exist. If you know there is a wrong way to do something, write a test case for it so that its caught as soon as someone does it.
Some of this would be easy to do if you already follow a test driven development process where you have to write tests before you write code.
The biggest difference between an organization which follows Continuous deployment and one which doesnâ€™t is in how QA is done. QA becomes a shared responsibility where everyone has to contribute. No matter how many tools or guidelines one publishes, if teams using this process donâ€™t believe in it, the quality and availability of website will suffer. Pascal-Louis Perez (from KaChing) used a diagram like the one here to explain how this â€œcultureâ€ is at the heart of continuous deployment.
â€œCultureâ€ also explains why most of the older organizations who follow a more traditional form of deployment are having a hard time understanding and adapting to this process.
Are you using Continuous deployments in your environment ? What was your biggest hurdle ?