Best practices for Azure configuration?

Question

So when we started our Azure migration we migrated our web.config settings over to the Azure configuration .cscfg file.

While this works, and is jolly useful in test environments as I can quickly hack the configuration, this seems rather dangerous in production... as I can quickly hack the configuration.

More formally, it means that it's easy for anyone with access to the Azure management console to make uncontrolled changes to a production Azure instance.

This strikes me as very bad.

So is there in practice any utility behind the .cscfg file beyond the standard diagnostic string configuration and so forth?

Answer 1

We like the flexibility of .cscfg files in testing, and we don't want to have a slightly different codebase for testing vs. production because we believe our testing environment should be an exact replica of the production environment...minus a few config differences.

At the same time, we're paranoid about some developer accidentally deleting the wrong deployment or changing the wrong .cscfg file/value. To solve this problem, we created two subscriptions, one for testing and one for production. We give all developers access to the testing subscription, but only those who are responsible for deployment have access to the production subscription.

The deployment engineers know exactly what they can and cannot do in a production environment (rebooting/reimaging instances, deleting deployments, etc.). They know that the ONLY .cscfg value to be touched in production is the "Instances count" property (our build server sets all other production .cscfg values).

So far, this setup has worked quite well for us.