21–26 of 26 posts
Could someone name other companies that do continuous deployment? I've only heard that IMVU uses buildbot.
IMVU has done continuous deployment for many years (way before it was cool). For details, I think this presentation is probably the best: http://www.slideshare.net/bgdurrett/sds-2010-continuous-depl... I've also contributed a chapter on it to the new O'Reilly Web Operations book: http://bit.ly/WebOperations
What about the user acceptance testing stage? The way the process was described in the article, looks like the process is code -> run unit tests -> run automated tests -> code review -> deploy. I may be missing something, but at which point are the features actually in front of the eyes of the business users who requested them? Unless programmers are business users themselves (which in Digg's case, I think is highly…
The whole point of continuous deployment is to separate code deployment from feature release. A typical way to orchestrate actual feature releases is to deploy the code ahead of time and later "flip a switch" to enable the feature. If you need to run it by test users, selectively enable the feature for just those users - there's your QA procedure.
Also, in this scenario you'd need to test every single combination, because what if you test A,B,C together, but then business wants to hold off on B, and if you enable A and C, that would break things?
And then enabling them for specific users only.. oy. What if it's a db schema change? Run db scripts to alter tables in production, every time we 'flip the switch'?
Earlier quoted context omitted.
The whole point of continuous deployment is to separate code deployment from feature release. A typical way to orchestrate actual feature releases is to deploy the code ahead of time and later "flip a switch" to enable the feature. If you need to run it by test users, selectively enable the feature for just those users - there's your QA procedure.
Hmm, I guess that would work, but it seems like an incredible amount of overhead to me. So you'd need to code that "switch" for every bugfix/feature? And even if there are libraries to do that, you'd still need to add custom code for every one. Also, in this scenario you'd need to test every single combination, because what if you test A,B,C together, but then business wants to hold off on B, and if you enable A and…
As for the complexity of testing permutations of features - that sounds like a problem with your Q&A process, no matter how you implement it.
As awesome as continuous deployment is, it is a large overhead to get going. This is especially true if you don't have high test coverage already. For smaller teams and projects, you can simply remove the automatic step. Invest some time in packaging and deploying your product in a repeatable, reliable way. And don't re-invent the wheel, really investigate the standard tools for your language and platforms.
I've tried to do continuous deployment for a smaller, one man, project and it was effectively impossible. It was too much infrastructure to maintain for one person.
The real question is does it save time at the end of the day? The overhead to set it up and keep it going is astronomical.
As awesome as continuous deployment is, it is a large overhead to get going. This is especially true if you don't have high test coverage already. For smaller teams and projects, you can simply remove the automatic step. Invest some time in packaging and deploying your product in a repeatable, reliable way. And don't re-invent the wheel, really investigate the standard tools for your language and platforms.
If the point of continuous deployment is to get rid of deployment pain, it fails miserably. I've tried to do continuous deployment for a smaller, one man, project and it was effectively impossible. It was too much infrastructure to maintain for one person. The real question is does it save time at the end of the day? The overhead to set it up and keep it going is astronomical.