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.
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.