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

Question

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

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

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

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

我们通过将单独的连接字符串添加到我们的 machine.config 来实现 #1，这样开发人员工作站设置之间就不会发生冲突。

我最初从 web.config 中删除了连接字符串部分。在 Azure 网站（使用管理门户，在配置下）中，我配置了连接字符串，在观看 Scott Hanselman 视频后，我的印象是这些将在部署时动态合并到我的 web.config 中，但事实并非如此似乎发生。每当我转到任何访问数据库的页面时，我都会收到一条错误消息，提示找不到连接字符串（或与连接相关的其他一些数据库错误）

如果我将 Azure 连接字符串直接放在 web.config 中，Things 可以在 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

Slow Cheetah 实际上是一个不错的解决方案。它是web.config transformations 的扩展。这些转换让您保留一个 web.config 文件，然后为每个部署方案指定您想要对其进行的更改。例如，您的发布配置可能会删除调试属性。

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

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

release/staging/.. 配置使用 web.config 转换将连接字符串元素替换为该部署的特定连接字符串（这样就消除了对外部配置文件的依赖）。

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