因此，当我们开始Azure迁移时，我们将web.config设置迁移到Azure配置文件.cscfg。Azure配置的最佳做法？
尽管这样做有效，并且在测试环境中非常有用，因为我可以快速破解配置，但这在生产中似乎相当危险......因为我可以快速破解配置。
更正式地说，这意味着任何有权访问Azure管理控制台的人都可以轻松地对生产Azure实例进行不受控制的更改。
这让我感觉非常糟糕。
那么在实践中有没有超出标准诊断字符串配置等.cscfg文件的实用程序？
我们喜欢的测试.cscfg文件的灵活性，我们不希望测试与生产有一个稍微不同的代码库，因为我们相信我们的测试环境应该是生产环境的完全复制品......减去一些配置差异。
与此同时，我们对某些开发者意外删除错误的部署或者更改错误的.cscfg文件/值有些偏执。为了解决这个问题，我们创建了两个订阅，一个用于测试，一个用于生产。我们为所有开发人员提供了测试订阅的访问权限，但只有负责部署的人才能访问生产订阅。
部署工程师确切知道他们在生产环境中可以做什么和不能做什么（重新引导/重新映射实例，删除部署等）。他们知道生产中只需要触及的.cscfg值是“实例计数”属性（我们的构建服务器设置了所有其他生产.cscfg值）。
到目前为止，这个设置对我们来说工作得非常好。
这也是我们所做的。对于SOX合规性（或任何其他合规性，idk），开发人员无法访问prod或prod配置。这也意味着我们必须有一个配置才能交给env团队来部署软件。一个不错的单一cscfg文件可以让你轻松完成任务。 –
根据您的安全&合规政策，你可能希望有一个自定义应用程序的设置解决方案的房子或许Azure存储或SQL Azure的所有应用程序的设置...
没有什么额外的“推荐“但它是非常有用的应用程序设置可用于改变W/O重新部署......
为了便于在Visual Studio环境之间切换，检查出我最近出版的@http://www.paraleap.com/blog/post/Managing-environments-in-a-distributed-Azure-or-other-cloud-based-NET-solution.aspx
博客条目>将应用程序设置更改为不重新部署可用于更改... <仅在测试环境中。我真的不希望这种无法控制的变化甚至有可能实现。如果我们需要在测试中调整设置，我很乐意做一个远程桌面和黑客'web.config' ... –
您仍然可以使用web.config在Azure中配置您希望保持不可配置的东西。我们将二者结合起来...
没有如此配置在这种情况下，意味着你将需要重新部署，以改变他们...
我正在寻找指导什么是“不那么可配置” - 你会考虑什么？ –
啊...指导...很难找到... :)无论是什么让你感到担忧，并不是一个问题，无法重新配置。我们有我们的数据库连接字符串和发送电子邮件和短信配置在那里（.cscfg），没有别的... –
...你可能也想要启用/禁用跟踪/登录。 （.cscfg再次...） –
仅通过限制访问Azure管理控制台就可以真正使用整个问题。如果有几个人需要部署，则可以创建证书供其使用，而不必授予他们对Azure管理控制台的访问权限。
实际上，我们的构建环境在部署到生产环境时会重新配置我们的配置文件。这基本上消除了进入管理界面的必要性，并且配置总是以相同的方式结束。
那么，你在Azure管理控制台上放谁？我希望这是一个安全的地方... –
我的配置_any_ uncontrolled更改的想法让我有点担心。即使我们仔细控制对控制台的访问。 –