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
[email protected]
- Bob Aiello's blog
- Login or Join to add your comment
User Comments
I'm with you, Bob, on a lot of points, especially "semi-automation". I want fingers and eyes on certain phases of the deployment, especially in production. I have developers who want to use the "push button" approach to get into production. Their argument is that logs can be reviewed after the deployment is complete. I tell them I want to see the errors as they happenen so I can stop the deployment if it's tracks if I need to. I also ask them how do I roll back a bad deployment if I need to. It doesn't happen often, but occasionally an issue pops up in production that wasn't detected in the development and test environments. Do I have a "roll back" push button?
I'm actually automated all the way through deployment to test evironments. I use the same scripts/programs for deployment to all environments. I just prefer that manual step to production. I can see some continuous delivery for simple changes - content changes (prices, images, etc.) or very simple production defects - spelling corrections on the UI and such - but I prefer we have some manual intervention points and approvals for anything more complex.
It's even tougher when you bring databases into it. Data persistance makes almost any automation insanely difficult. But, it is achievable to at least automate the creation of the deployment artifact. I still want that chance to review and validate (let alone test, test, test) prior to production. So Continuous Deployment might not be a goal I'd set, but if we define Continuous Delivery as the mechanism of generating that artifact, that's one I can get behind. To start with, I'd say your database code has to go into source control with your application code. That's the easy part. The hard part is, as you say, automating things after that. I wrote up an article on why to get your databas into source control here: https://www.simple-talk.com/sql/database-administration/why-put-your-database-into-source-control/