Continuous Deployment
I’ve written before about the amazing financial impact of releasing more often. And I know from personal experience the positive impact that frequent releases have on learning and on product quality and value. So, I enjoyed this post on one company’s experience with continuous releases. Yes, you read that right; they release, on average, 50 times per day.
We call this process continuous deployment because it seemed to us like a natural extension of the continuous integration we were already doing. Our eventual conclusion was that there was no reason to have code that had passed the integration step but was not yet deployed.
Read the whole thing and consider what it would take in your organization to get to continuous deployment. How fast could you go? And what impediments would have to be resolved to make it happen?
We’re struggling with a Waterfall (or trickle) QA and business process. We can barely get a deployment that’s been sent through one set of testers on to the next and final approval for UAT and then production.
We’ve had to adopt a branching process that is just brutal on code management. I’ve been the minority voice preaching one branch and if not continuous, at least higher rate of output, deployments. Management and QA aren’t having it. The change control on the whole thing seems unnecessary and expensive to the business. The business rarely sees new functionality and enhancements to the application.