你如何处理源代码管理中的配置文件?

dea*_*mer 90 svn git cvs version-control

假设您有一个典型的Web应用程序和文件配置.无论如何.每个开发该项目的开发人员都有一个版本用于他们的开发盒,将有一个dev,prod和stage版本.你如何在源代码管理中处理这个问题?根本不检查这个文件,用不同的名字检查或完全做些什么?

yuk*_*ude 64

我过去所做的是拥有一个默认配置文件,该文件已签入源代码控制.然后,每个开发人员都有自己的覆盖配置文件,该文件从源代码管理中排除.应用程序首先加载默认值,然后如果存在覆盖文件,则加载该文件并使用覆盖中的任何设置优先于默认文件.

通常,覆盖文件越小越好,但对于具有非常标准环境的开发人员,它总是可以包含更多设置.


dav*_*000 21

配置代码,您应该对其进行版本控制.我们将配置文件基于用户名; 在UNIX/Mac和Windows中,您都可以访问用户的登录名,只要这些名称对项目是唯一的,您就可以了.您甚至可以在环境中覆盖它,但您应该版本控制所有内容.

这还允许您检查其他人的配置,这有助于诊断构建和平台问题.

  • +1绝对强调该配置仍应进行版本控制 (8认同)

Gra*_*ant 19

不要版本该文件.版本模板或其他东西.

  • 我使用这种方法,我只有一个main.php.tmpl,当我签出一个新的副本时,只需将它复制到main,php.我将main.php文件添加到忽略列表中,以避免意外提交. (2认同)

Bra*_*ood 9

我的团队为每个环境保留了不同版本的配置文件(web.config.dev,web.config.test,web.config.prod).我们的部署脚本会复制出正确的版本,并将其重命名为web.config.这样,我们对每个环境的配置文件进行完全版本控制,可以轻松执行差异等.


Gat*_*ler 6

目前我有"模板"配置文件,其中添加了扩展名,例如:

web.config.rename
Run Code Online (Sandbox Code Playgroud)

但是,如果关键更改发生了变化,我可以看到此方法存在问题.


Dam*_*ren 5

模板方法+1.

但是由于这个问题有标签Git,因此需要考虑分布式替代方案,其中自定义保存在私有测试分支上:

A---B---C---D---           <- mainline (public)
     \       \
      B'------D'---        <- testing (private)
Run Code Online (Sandbox Code Playgroud)

在此方案中,主线包含一个通用的"模板"配置文件,需要进行最少量的调整才能生效.

现在,开发人员/测试人员可以将配置文件调整到他们内心的内容,并且只在一个私有测试分支上本地提交这些更改(例如B'= B +自定义).每次主线前进时,它们都会毫不费力地将其合并到测试中,从而导致合并提交,例如D'(= D + B的自定义的合并版本).

当"模板"配置文件更新时,这个方案真的很闪亮:来自双方的变化被合并,如果它们不兼容,极有可能导致冲突(或测试失败)!


Jas*_*son 5

我们使用的解决方案是只有单个配置文件(web.config/app.config),但我们在文件中添加了一个特殊部分,其中包含所有环境的设置.

有一个LOCAL,DEV,QA,PRODUCTION部分,每个部分都包含配置文件中与该环境相关的配置键.

使这一切工作的是一个名为xxx.Environment的程序集,它在我们的所有应用程序(winforms和webforms)中引用,它告诉应用程序它正在运行的环境.

xxx.Environment程序集从给定计算机的machine.config读取单行信息,告知它它在DEV,QA等上.此条目出现在我们所有的工作站和服务器上.

希望这可以帮助.


Jac*_*Ace 5

我一直将所有版本的配置文件保存在源代码管理中,与 web.config 文件位于同一文件夹中。

例如

web.config
web.qa.config
web.staging.config
web.production.config
Run Code Online (Sandbox Code Playgroud)

我更喜欢这种命名约定(而不是 web.config.production 或 production.web.config),因为

  • 当您按文件名排序时,它会将文件保存在一起
  • 当您按文件扩展名排序时,它将文件保持在一起
  • 如果文件不小心被推送到生产环境,您将无法通过 http 查看内容,因为 IIS 将阻止提供 *.config 文件

应配置默认配置文件,以便您可以在自己的机器上本地运行应用程序。

最重要的是,这些文件应该在各个方面几乎 100% 相同,甚至格式。您不应该在一个版本中使用制表符,而在另一个版本中使用空格来缩进。您应该能够对文件运行 diff 工具以准确查看它们之间的不同之处。我更喜欢使用 WinMerge 来区分文件。

当您的构建过程创建二进制文件时,应该有一个任务用适合该环境的配置文件覆盖 web.config。如果文件被压缩,则应从该构建中删除不相关的文件。