管理连续部署到Azure网站的源控制应用程序中的连接字符串

Question

这是场景：我在asp.net mvc 4项目上有多个开发人员。每个开发人员都有一个本地数据源控制系统是http://tfs.visualstudio.com的TFS。我们使用Azure网站来托管该网站。我们还配置了Azure网站以进行持续部署。

源代码控制系统可能是git，mercurial，TFS等。老实说，我认为这不重要。

我的问题是如何完成这三件事：

1. 每个开发人员在本地都有自己的连接字符串（没有它们在源代码管理中）
2. Azure有自己的连接字符串（没有它在源代码管理中）
3. 源代码管理未显示任何连接信息
4. 每个开发人员都能够在本地运行/调试/测试应用程序。

我们通过将我们的各个连接字符串添加到machine.config来完成＃1，这样开发人员工作站设置之间就没有冲突。

我最初从web.config中删除了connectionstrings部分。在Azure网站（使用管理门户，在配置下），我配置了连接字符串，在观看了Scott Hanselman视频之后，人们认为这些视频会在部署时被动态地合并到我的web.config中，但这并不是似乎发生了。每当我访问任何命中数据库的页面时，我都会收到错误消息，说找不到连接字符串（或者与连接相关的其他数据库错误）

如果我将Azure连接字符串直接放在web.config中，那么在Azure上工作，但是连接详细信息在每个人都可以看到。

在阅读了Scott和David Ebbo的更多帖子之后，似乎我可以在web.config（使用正确的名称）中添加一个空白连接字符串，然后Azure将正确覆盖这些值。然后，我必须让开发人员将他们的连接字符串放在他们的web.debug.config中，然后安装Slow Cheetah插件，以便他们可以在本地进行F5测试。他们还必须不将web.debug.config检入源代码控制。 （TFS并不那么容易）这看起来像是一个非常繁重的垃圾，它必然会在某个地方失败。

我必须相信这不是一个罕见的问题。其他团队如何实现这一目标？

Answer 1

环顾四周之后，如果没有一堆命令行破解前/后构建过程，看起来我所要求的实际上并没有得到支持。我们最终做的是强制开发人员创建自己的本地数据库，使用受信任的身份验证，并建立Web.config中所有开发人员使用的SQL别名。这样，它在本地为每个人工作，它不会在源代码管理中公开任何用户名/密码，并且Azure在从源代码管理中自动提取时仍然可以覆盖它。

Answer 2

慢猎豹实际上是一个不错的解决方案。它是web.config transformations的扩展。这些转换允许您保留一个web.config文件，然后为每个部署方案指定您想要的更改。例如，您的Release配置可能会删除debug属性。

这也可用于更改连接字符串。在将项目部署到Azure期间应用转换。

我过去所做的使用本地开发机器的方法是使用带有externalized connections.config file的web.config。每个开发人员都创建了一个connection.machinename.config文件，该文件在构建后步骤中复制到build上的connection.config。这些文件不必签入，它们永远不会引起冲突，因为每个机器名称都是唯一的。

release / staging / ..配置使用web.config转换将连接字符串元素替换为该部署的特定连接字符串（并以此方式删除对外部配置文件的依赖性）。

Slow Cheetah提供了一些很好的帮助，可以在设计时检查这些转换的结果。