2008-10-07 62 views
8

现在我们的测试和生产数据库位于同一台服务器上,但名称不同。部署意味着编辑Web.config以更改正确数据库的所有连接字符串。一个我忘记太频繁的步骤...如何在部署ASP.NET网站时处理连接字符串?

我们终于创建了一个新的数据库服务器进行测试,并且我将数据库移动到了......但现在服务器将会不同,我们仍然会需要处理连接字符串问题。

我正在考虑通过主机文件来管理它,但是当我需要对生产数据进行测试时,在桌面计算机上切换它的想法看起来很麻烦。

所以我只是想知道是否有更好的出路。东西会建立一个“生产”的web配置部署将是理想...

回答

1

有独立CONFIGS环境的文件夹为每个环境

部署了一个正确的环境

5

我通常有三个独立的Web配置:一个用于我的开发机器,一个用于QA,另一个用于生产。开发人员连接到我的本地SQL数据库(从外部防火墙),它是默认的web.config。其他人被命名为web-prod.config和web-qa.config。发布后,我删除了我不需要的两个,并将正确的一个重命名为web.config。如果我忘了,应用程序第一次尝试访问数据库时会中断,因为默认配置引用了它无法访问的配置。

因为IIS拒绝提供名为.config的文件,所以我确定它们都以.config而不是web.config-prod或web.config-qa结尾。

+0

这些数据库太大而无法在SQL Express中运行......但我认为我可以使用我们的防火墙来确保生产版本不会连接到错误的数据库。 – CodeRedick 2008-10-08 14:09:27

+0

我有本地安装的SQL Server的开发者版本,而不是SQL Express。无论如何,我绝不会在我的本地系统上拥有整个生产数据,只是一些测试数据。 – tvanfosson 2008-10-08 16:03:36

1

我经常这样做,我只在生产服务器上对web.config进行了只读。

6

使用Web Deployment Project并更新wdproj文件(它只是一个MSBuild文件)与一些后构建任务输出正确的.config文件。我把一个web.config和web.release.config然后在wdproj文件中使用此:

<Target Name="AfterBuild"> 
    <Copy Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\web.release.config" DestinationFiles="$(OutputPath)\web.config" /> 
    <Delete Files="$(OutputPath)\web.release.config" /> 
</Target> 

More information

一个简单的办法有的喜欢用configSource property of appSettings and connectionStrings从来就不是覆盖生产服务器上的文件。

+0

我应该认为这与VS2008中的“Web Setup Project”是一样的吗?看起来这可能是一个好主意... – CodeRedick 2008-10-07 21:38:01

2

这里是另一回事,你可以尝试:

使用SQL Server配置管理器,使数据库别名为您的开发数据库,​​以便在web.config文件可以在你的开发框和生产服务器都相同。

0

我将我的连接字符串放在我们的QA和生产框中的machine.config中。不过,我会将它们保存在我的开发盒中的web.config中以获得灵活性。然后,在部署到QA时,我将使用Web部署项目来覆盖我的开发连接字符串(没有任何连接字符串)。因此,QA站点依赖于machine.config中的连接字符串。我仍然手动部署到Production,以确保一切顺利。我通过手动将QA中的所有内容(web.config除外)复制到生产环境来实现此目的。

2

我在每台服务器上创建一个数据库别名来指向数据库。然后我在我的web.config文件中使用这个别名。如果我需要更改应用程序指向的数据库,则更改别名而不是web.config。

对于SQL Server,请转到SQL Server配置管理器> SQL本机客户端配置>别名>创建新别名。

您可以使用tnsnames文件对Oracle执行相同的操作。

0

这种类型的任务正是构建事件旨在解决的问题。考虑为特定目标构建构建,应该在那里完成任何目标特定配置。 (与正常的警告说,总是有一些例外的规则)

1

我一直在几个地方,现在将他们存储在注册表中。

现在可能有更复杂的方法来做到这一点,但我已经使用1.0/1.1遗产的很多代码在注册表中存储了字符串。

注册表有几个优势

  1. 它使人们从代码部署到错误的地方,因为没有正确配置的机器将缺乏键
  2. 它消除了其中一个开发人员不小心打包的问题web.config文件中包含开发连接字符串(接着在半夜疯狂地打电话,其中显示深夜系统管理员没有备份先前的web.config并且开发人员不知道或回想起生产字符串)
  3. 它限制了位置黑客能否通过从机器上取回web.config来获取连接字符串。此外,注册表具有比文件系统更高级别的安全性。
1

我们从CI服务器驱动部署。我们通常为每个位置都有一个单独的文件,并根据传递的参数将CI服务器切换到适当的配置。所有的文件编辑都是在NAnt脚本中完成的,因此开发人员可以在他们的机器上运行sam构建以获取他们自己的设置。

0

我最近一直倾向于持续集成服务器上的配置操作。这是因为我们遇到了多个web.config,web.qa.config,web.production.config等问题,请保持95%的文件应该保持同步。

简而言之:在源代码控制中只有一个web.config,它是开发配置(调试友好的,本地数据库等)。构建服务器执行编译,然后部署到金丝雀网站,然后进行发布候选软件包。

我们使用nant,所以它是.build文件,它具有设置debug =“false”的xmlpoke,alter connection字符串以及其他需要在canary副本中更改的内容以及web.config的打包副本。

构建机器的部署被称为“canary”,因为如果出现问题,它首先会死亡。