Continuous deployment is an enhanced process of continuous integration. The idea is simple, code is created, it is then merged with the baseline several times a day, it goes through a period of automated testing and then it is deployed into the production environment. That’s right - this happens several times a day.
Compared to the “old school” approach to programming, continuous deployment probably makes you nervous. In the traditional model – you develop for a period of time (say 3+ months), then you test for a period of time, then you bug fix for a while, then you test for a while more and eventually you deploy your software. This leaves your customers waiting for months or even years for minor bug fixes and new features.
The advantage of the traditional approach is simple. When the product is ready to go, it should be in the perfect state for release. That means fewer bug fixes, patches, helpdesk calls, etc. right? Well, not so much really. Microsoft has a famously long development cycle for Windows releases and yet that didn’t stop them from releasing abominations like Vista or the truly abysmal Millennium Edition did it?
So the key with continuous deployment is to learn to manage the risk. The way that continuous integration works is that the code is automatically compiled onto a build server and then hit with a battery of automated testing (at a minimum all unit tests need to be conducted quickly). This allows you to keep your development team well informed of any issues in new branches and lets them fix those problems quickly.
In order for continuous deployment to be effective, effort needs to be focused on your build servers and your automated testing. Testing for continuous deployment needs to be extremely sensitive and it needs to catch pretty much every single error imaginable. You need to develop highly sensitive unit tests - Timothy Fitz, one of the main proponents of continuous deployment recommends tests that don’t allow more than 1 in 1 million errors to sneak through without being caught. You can then ensure that when you deploy, your clients are only going to experience working functionality that functions exactly as it is expected to.
Tests that only let 1 in 1 million errors go through are extremely viable with today’s testing development tools. The key is to accurately define your tests for all possible scenarios – something that wasn’t possible even a few years ago because of the amount of raw resources it took to run exacting unit tests. Now, with cloud computing and virtualization it should be simple to harness the resources to test for continuous deployment.
Of course, there is always the risk of a problem creeping into the customer environment even when the risk is minimal. So there’s a need to support continuous deployment methodologies with a fail- safe roll back plan. However, if your tests cases are properly defined, results in real-life scenarios have shown that it’s rare for organizations using continuous deployment to have to reach for their fail-safe.
- Fast and regular roll out of patches, bug fixes and new functionality – your clients get to see rapid progress on your daily releases rather than waiting forever.
- It’s a natural byproduct of continuous integration methodologies – why invest all that money in better development if you’re still going to leave the finished product on the shelf.
- It drives better levels of attention to detail and care within development teams – developers know that their code could be live in hours and not in years when issues might well be “someone else’s problem”.
- It leads to better quality not just in releases but also in the focus of your testing which becomes much more thorough.
Making the switch to continuous deployment doesn’t need to be a headache. Working with a devops (development and operations) team can help enable a hassle free switch to continuous deployment with major benefits for your coders and customers alike.