半可编辑文件(如配置文件)和版本控制-最佳实践?

您所能做的就是拥有一个保持不变的默认配置文件,除非添加了一些新的配置。然后,您将有一个不同的文件来覆盖默认文件的配置。

config.Default.xml
config.User.xml

只有配置。Default.xml受源代码控制。配置。User.xml仅包含与您不同的配置。因此,假设您正在本地SQL服务器上进行测试,您只将连接字符串放入其中,它将覆盖配置。默认连接字符串。

请看。Net Framwork应用程序配置,它为您完成大部分(如果不是全部)工作。

我使用的一种方法是拥有两个版本的配置文件,并让安装程序脚本提取正确的版本。

• settings.xml-释放

这两个文件都包含相同的键,但一个包含“dev”值,另一个包含我们希望在字段中部署和编辑的值。

• *.(配置|xml)
• *.(config|xml).cert
• *.(config|xml).production

Hudson删除初始文件,并为正确的环境部署正确的文件(目前只有证书)。

我们将这类文件存储在源代码管理系统中,并为我们构建的环境设置了不同的文件夹。

所以我们有:

Dev
Test
Live

这些文件夹下有其他特定于环境的文件的子文件夹。

我认为公认的答案是好的,但根据你的要求,它可能有局限性。

我们采用以下方法。请注意,我们是。NET商店使用VS,并利用MSBuild(内置、社区和自定义)任务。

• App.config
• App.default.config

项目的BeforeBuild任务寻找以下项的存在 App.config 如果找不到副本 App.default.config 向 App.config 此外,构建服务器始终会删除 App.config 如果它存在于CI构建中(确保配置干净)。然后,我们还使用MSBuild Community FileUpdate任务,根据构建项目的内容,用适当的值替换令牌。

例如,新开发人员签出可以为本地数据库设置db连接字符串,夜间构建可以为夜间db设置,等等。

部署的配置文件存储在我们的源代码管理提供程序中的单独位置。如果有人需要对即将部署的配置进行更改,他们必须修改此版本。

对于每个配置文件x,创建一个名为x.dist的文件进行签入,这是默认的分布式配置。开发人员签出后,有一个脚本将每个x.dist文件复制到x,在那里他们可以根据需要自定义x。此脚本可以在发生重大更改后重新运行以更新文件,或者开发人员可以手动合并他们的更改。

对于部署,您可以签入实时部署文件,并让启动脚本明确引用它们(例如--config x.product)。

例如,这种方法用于 Wordpress 是分布式的(您必须复制一个模板wp-config.php文件)或在使用autoconf的开发项目中(其中检入了configure.ac,但配置文件必须由每个开发人员生成;在发布时为在tarball中分发构建了一个特殊的配置文件)。