如何处理Subversion中不同系统上配置文件的部署?

为了解决这个问题,这种配置应该被视为“部署细节”,而不是整个应用程序配置。 即使在进行概念上的区分时,您仍然需要处理不同的部署环境,但是,由于您似乎在处理PHP,我无法对您的案例的具体细节发表评论。

正如Lars提到的,一个可能的J2EE解决方案是将这些细节存储在JNDI下,使完全相同的二进制应用程序可以部署在任何环境中,让DBA/Admins为每台机器设置用户名/密码。

[general]
info=misc
db.password=secret
db.host=localhost

[production : general]
info=only on production system
db.password=secret1

[testing : general]
info=only on test system
db.password=secret2

[dev : general]
info=only on dev system
db.password=secret3

因此dev:db.password=='secret3',但是dev:db.host=='localhost',来自原始的“general”组。

“production”、“testing”和“dev”可以是计算机主机名,也可以是从配置控制脚本中的其他机制设置的别名。

在我目前从事的项目中,我们有两个数据库模式信息的属性文件——一个用于生产环境,一个用于开发。我们有一个类,用于加载正在执行的模块的所有属性,逻辑决定加载哪个文件。

由于我们本地的开发环境是Windows文件系统,生产服务器在UNIX文件系统上运行,因此我们的解决方案是确定主机的操作系统并加载正确的文件。

我们将这些直接保存在源代码管理中,以便保存所做更改的历史记录。我认为我们从我们的(内部)客户在以下方面的指责中吸取了教训: 异常频繁的需求变更

这对于我们的情况来说可能是独一无二的,但我发现这非常有帮助,特别是当我试图复制以前版本的测试运行时。

一些可能的解决办法:

您可以在subversion服务器中有一个默认属性文件,但可以在服务器上的其他位置(在项目签入svn的部分之外)查找真实属性文件,但是通常会得到依赖于操作系统的路径,并且在svn文件中添加新属性时,必须记住手动更新真实属性文件。

可以将属性文件中的属性设置为生成的一部分,并将参数传递给build命令,以告诉它要为哪个服务器环境生成。这感觉有点迂回,您必须记住使用新属性更新构建脚本。但它可以很好地工作——如果您设置了一个持续集成服务器,它可以为所有不同的环境构建并为您测试捆绑包。那你就知道你已经准备好了。

您还可以使配置文件依赖于域。通过这种方式,您可以为本地计算机和生产服务器创建配置。当然,您需要构建逻辑来处理这个问题。