By now you know that Assembla supports continuous delivery, a process for releasing changes every day. We’ve offered up the secret sauce and explained our own experience. However, most teams cannot release every day. Maybe they make products that are distributed much less frequently, or maybe their systems require additional steps like localization, user acceptance testing, and management signoff. For these cases, we present the “Continuous Delivery Dial,” from Steve Brodie and Rohit Jainendra at Serena.
The dial represents the steps you take to release software from design and development on the left, to final release on the right. You can run continuous delivery in your development process up to a certain point on the dial. After that point, you drop the software into a “release train,” as Serena calls it, where it goes through some batch processes. You can adjust the point where you drop into the batch process.
Serena has built a Release Manager product which helps you track the releases in your train, along with a Deployment Manager that builds the destination servers, delivers the releases, and tells you where they were delivered. One of our customers calls the point where developers decide what gets loaded into a release “the dock,” so I guess they have release boats instead of a train. I’m going to get my guys some imaginary jets.
Why would you want to run continuous delivery only on the development side of the release cycle?
1) In our experience, continuous delivery is less annoying and less stressful for developers. It’s annoying to send stuff away for QA and then get it back with a bug report two weeks later which results in having to drop what you are now working on and set up the whole development scenario again. If you can get into a lean process like continuous delivery, you might be able to actually work on one thing, finish it, and go on to the next thing.
2) The continuous delivery process is also more scalable than iterative processes. As you increase the size and productivity of your development team, you have more stuff to integrate and test in every iteration. If the integrate and test phase starts getting longer, you might have to move to continuous delivery.
3) You might want to increase the speed or frequency of your release process so you move the development process to continuous delivery, and then work on the rest of the “dial.”
You probably already have several versions of the "dial" already. For example, most teams use fewer release steps for a high priority bug fix, than for a big new feature. The dial gives you a convenient way to talk about the release process in each case.
Spinal Tap fans will be happy to learn that there is an “11” on the continuous delivery dial. Some Web sites put a change onto production servers, measure what happens, and then if it works, merge it back into their gold master version. I call this the 11 because you are sending changes to users before accepting them into a release. It’s risky, but it’s an effective testing process that makes the gold master version cleaner for the other developers.