6

这是场景：我在一个 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 不是那么容易）这似乎是一个非常繁重的组合，它肯定会在某个地方失败。

我必须相信这并不是一个罕见的问题。其他团队如何做到这一点？

4

2 回答 2

4

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

于 2013-04-15T21:18:15.527 回答
1

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

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

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

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

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

于 2013-04-12T18:19:34.680 回答