在持续部署到 Azure 网站的源代码控制应用程序中管理连接字符串 [英] Managing connection strings in source controlled application that is continuously deployed to Azure websites
问题描述
以下是场景:我在一个 asp.net mvc 4 项目上有多个开发人员.每个开发人员都有一个本地数据库.源代码控制系统是位于 http://tfs.visualstudio.com 的 TFS.我们使用 Azure 网站来托管该网站.我们还为持续部署配置了 Azure 网站.
Here's the scenario: I have multiple developers on an asp.net mvc 4 project. Each developer has a local database. The source control system is TFS at http://tfs.visualstudio.com. We're using Azure websites to host the site. We have also configured Azure websites for continuous deployment.
源代码控制系统可以是 git、mercurial、TFS 等.老实说，我认为这并不重要.
The source control system could be git, mercurial, TFS, etc. Honestly, I don't think it matters.
我的问题是如何完成这三件事:
My question is how to accomplish these three things:
- 每个开发人员在本地都有自己的连接字符串(它们不受源代码控制)
- Azure 有自己的连接字符串(不受源代码控制)
- 源代码管理不显示任何连接信息
- 每个开发者都能够在本地 F5 并运行/调试/测试应用.
我们通过将单独的连接字符串添加到我们的 machine.config 来实现 #1，这样开发人员工作站设置之间就不会发生冲突.
We accomplished #1 by adding our individual connection strings to our machine.config so that there's no conflict between developer workstation setups.
我最初从 web.config 中删除了连接字符串部分.在 Azure 网站(使用管理门户，在配置下)中，我配置了连接字符串，在观看 Scott Hanselman 视频后，我的印象是这些将在部署时动态合并到我的 web.config 中，但事实并非如此似乎发生.每当我转到任何访问数据库的页面时，我都会收到一条错误消息，提示找不到连接字符串(或与连接相关的其他数据库错误)
I originally removed the connectionstrings section from web.config. In the Azure website (using the management portal, under Configure), I configured the connection strings, and after watching a Scott Hanselman video was under the impression that these would be dynamagically merged into my web.config upon deployment, but that doesn't appear to happen. Whenever I go to any page that hits the db, I get an error saying can't find the connection string (or some other db error related to the connection)
如果我将 Azure 连接字符串直接放在 web.config 中，Things 可以在 Azure 上运行，但是连接详细信息在源代码管理中对所有人可见.
If I put the Azure connection string directly in web.config, Things work on Azure, but then the connection details are in source control visible to everybody.
在阅读了 Scott 和 David Ebbo 的更多帖子后，我似乎可以在 web.config 中放置一个空白连接字符串(使用正确的名称)，然后 Azure 将正确覆盖这些值.然后，我必须让开发人员将他们的连接字符串放在他们的 web.debug.config 中，然后安装 Slow Cheetah 插件，以便他们可以 F5 并在本地进行测试.他们也不必将 web.debug.config 签入源代码管理.(使用 TFS 不是那么容易)这似乎是一个非常繁重的组合，肯定会在某个地方失败.
After reading some more posts from Scott and David Ebbo it seems that I could put a blank connection string in web.config (with the correct name) and then Azure will overwrite the values correctly. I would then have to have the developers put their connection strings in their web.debug.config and then install the Slow Cheetah plugin so that they could F5 and test locally. They would also have to not check in the web.debug.config into source control. (Not that easy with TFS) This seems like a seriously burdensome kludge, that's bound to fail somewhere along the line.
我必须相信这并不是一个罕见的问题.其他团队如何做到这一点?
I have to believe that this isn't that rare of a problem. How do other teams accomplish this?
推荐答案
环顾四周后，如果没有对前/后构建过程进行大量命令行黑客攻击，似乎实际上不支持我的要求.我们最终做的是强制开发人员都创建自己的本地数据库，使用受信任的身份验证，并在 web.config 中建立所有开发人员都使用的 SQL 别名.这样，它就可以在本地为每个人工作，它不会在源代码管理中公开任何用户名/密码，并且当自动从源代码管理中提取时，Azure 仍然可以覆盖它.
After looking around, it appears that what I was asking isn't actually supported without a bunch of command line hacks to the pre/post build process. What we ended up doing is forcing developers to all create their own local databases, use trusted authentication, and establish a SQL alias that was used by all developers in the web.config. That way, it works locally for everybody, it doesn't expose any user names/passwords within source control, and Azure can still overwrite it when automatically pulled from source control.
这篇关于在持续部署到 Azure 网站的源代码控制应用程序中管理连接字符串的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
