发布配置管理

Question

我们的Windows可交付产品为不同的客户提供了不同的配置文件和二进制资产。现在，配置是在包装之前手工完成的，并且容易出错。您如何看待为每个客户使用分支机构，并使用软件包构建/脚本自动将客户的分支机构与主干分开？

我对可扩展性的关注程度低于我自动获得ASAP的能力。

整个packag内容都是SVN，但SVN分支和合并是如此微妙，以至于我不相信它在自动化时能够始终如一地工作。如果你们喜欢这个想法，我可能会尝试使用git-svn，因为它有望使合并变得不那么精致。我们不一定要合并资产，因为它们是有组织的，所以安装程序可以跳过不适当的目录树，但配置并不那么简单。

Answer 1

我想这取决于有多少事情要改变。对于配置文件，我喜欢将单个文件保留在源代码管理下，并使用构建脚本来设置特定于环境的（或在特定于客户端的情况下）项目。

http://automaticchainsaw.blogspot.com/2008/02/automate-config-changes-for-different.html

对于二进制文件，它可能更多地与您拥有的数量以及它们来自何处有关。如果它们是代码编译的一部分，那么理想的编译过程将创建您需要的内容。如果它们是其他资源（例如图形），则可能在一个目录下有一组客户特定的文件夹。构建脚本将根据传递给脚本的参数拉入正确的客户端文件夹。这基本上是您在问题中提到的分支和合并想法。

关于稍后关于多行配置更改的评论 - 假设它是xml，您可以查看MSBuild社区任务中的XmlMassUpdate类。我自己没有用它，但看起来它可能就是你需要的东西。

Answer 2

您没有提及哪种语言，但您可以考虑执行conditional compilation：

#If FirstCustomer Then
   ' <code specific to the FirstCustomer version>.
#ElseIf SecondCustomer Then
   ' <code specific to the SecondCustomer version>.
#Else
        ' <code specific to other versions>.
#End If

Answer 3

这可能发生在不同的客户，环境（QA，登台，生产......），地区（美国，欧盟，亚洲......）或不同的应用程序类型（如果您必须在服务时配置服务器）移动客户端而不是网络或桌面移动客户端。）

通常，人们要么手动维护配置文件（如你所提到的），这样容易出错并且不安全。或者像佩德罗提到的那样，使用构建脚本“窥视并捅”配置文件中的正确值。这种方法还意味着对于影响配置的每个代码更改，脚本也应该更改哪个不理想。此外，调试和测试这些脚本（无论它们使用何种语言）通常很难（如果不是不可能的话）。

面对您的确切问题，我们开发了一个基于中央配置服务器的解决方案，为客户端提供配置服务。服务器支持值的继承，更改的审计和版本控制，模板甚至是实时推送到客户端的运行时更改。

我们非常接近将此服务作为云托管配置管理解决方案发布。如果您想尝试一下，请在http://woot.configchief.com

注册测试版