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.
Actually, continuous deployment does not necessarily need to be automated. In my experience, it's possible to get going with it in a totally incremental way. One easy way to get started is with this post:
http://radar.oreilly.com/2009/03/continuous-deployment-5-eas...
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.
For a larger, more complex project, it's a godsend though. Not just in terms of saving time, but also in terms of preventing errors that happen when you do things manually.
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 unlikely), it's very risky for business users who requested the features to first see them in production. Even with all the tools that they have, the chance of simple misunderstanding and "No-no, that's not what I meant!" is always there. That's why I think there should always be a user acceptance stage, where users get to play around with the release (ideally, with data as close to production one as possible), and 'ok' the release for production from there.
Also they didn't mention QA at all. Unless QA are the ones that are writing Selenium tests at the same time devs are coding the feature.
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 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'?
If a user can't see the feature, it doesn't exist. Typically enabling a feature means revealing it at the view layer, which is quite simple. Any DB schema change can take place ahead of time.
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.
Has a regular user of Digg and an alpha tester for Digg4, I have to say I am quite impress with the rapidity and the quality of the changes. The real-time digg count updates give quite a good feeling to the website in general since you have a feeling to participate in something bigger. The update has been on the right track and I hope the best for Digg.
The "my news" front page has made it vastly more useful for finding things I'm interested in. Though until it's out of beta and friends can use it fully it still feels a bit like the "like" button in google reader.
Buildbot is used for continuous integration, which is a big step along the path to continuous deployment. A lot of companies are doing this today. Fewer are doing continuous deployment. kaChing has some posts about their setup:
Yeah, it's important to make the distinction between continuous deployment and continuous integration.
Continuous integration is a fairly simple thing: detect a new source commit, run a battery of tests on it, report back. Hudson is a really good one (of which the original author is a main contributor, and I did some plugin work for a while), and I use it as a fairly fancy looking cron as well.
Continuous deployment, as described in the article, is much more difficult. Not only do you have the slew of tests, but maybe you want more long-running tests that you don't care to run all the time. Maybe you want code reviews. You'll need to automate the actual deployment process and so on.
Automattic/Wordpress.com does either automated Continuous Deployment or have their deployments so streamlined that releases are made very frequently and are (almost always) non-events.
I wonder if any company will see an opening to create an easy process utilizing all those programs which I assume have to be individually setup? I'm sure if it was easier to configure more teams would utilize that method of deployment.
