Continuous Delivery and other bad ideas
There are many articles on why continuous delivery is essential to deliver changes to applications in a fast and reliable way. Many authors cite case studies in which successful organizations deliver code continuously throughout the day - every day. My own colleagues often ask me how to implement continuous deployment. My first reaction is to ask them why they want to?
Most organizations cannot keep up with daily changes from a business and product perspective. Delivering features but not turning them on is a viable solution but again sometimes more work than necessary. In my opinion, Continuous delivery can be overkill and sometimes totally unnecessary. What really is needed is reliable, secure and repeatable deployments that utilize a reasonable amount of automation. Getting scripts to build, package and deployment with a one-button click takes a fair amount of work. My experience is that scripting each step with an operator viewing the output and hitting enter a few times takes much less work than a completely automated single button deploy. I call this approach "semi-automated" deployment which still results in reliable, secure and repeatable procedures - albeit without the nervana of a single button deploy. Its been my experience from a very young age that learning to walk before you run is a pragmatic approach. So often do you really need to deploy your code?
The cadence that I have seen most often work effectively is moving from one deployment every two months to deploying twice a week. Smaller deployments work much better than big deployment with many moving parts. When I join a group I always ask to do as many deploys as possible and I start in development test (often called DIT). This approach is called "left-shift" and refers to getting operations involved earlier in the process.
Continuous delivery and continuous deployments are certainly appropriate in many situations. But starting with reliable, secure and repeatable procedures will help you reach the finish line much faster while controlling risks and costs.
What is your opinion?? Drop me a line and share your best practices!
Bob Aiello, Technical Editor CM Crossroads