管理源代码控制的应用程序中的连接字符串，该应用程序连续部署到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，mercury，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中删除connectionstrings部分的.在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中，那么事情就可以在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屋！
