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.
