IMO, the existance of code to configure more then one production-like environment is an anti-pattern. The remedy is using configuration management (Chef/Puppet/whatever) to put the correct environment specific configuration into place in a non-executable config file. Any other policy will lead to environmental drift.
I'm not sure there is a substantive difference between "code" and a "non-executable config file". The latter is something that is read by an executable and which results in specific execution that differs by the content of the file; the difference between this and interpreted code is semantic rather than substantive.
E.g., for any combination of a YAML configuration file and a Ruby function which reads and applies it, there is a corresponding Ruby function which achieves exactly the same result without the configuration file.
There are other reasons to prefer the config file approach, but a policy which deploys the correct code to each environment will have exactly the same behavior with regard to environmental drift as one which deploys identical code the correct config file.
This is what we do, but we can also do his rollout example in production by putting both new and old into production side by side and then targeting percentages of new users.
