3

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

我不太关心可伸缩性，而是更关心尽快实现自动化。

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

4

3 回答 3

2

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

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

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

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

于 2008-11-11T16:31:17.833 回答
0

您没有提及哪种语言，但您可能会考虑进行条件编译：

#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
于 2008-11-11T17:30:59.350 回答
0

这可能发生在不同的客户、环境（QA、Staging、Production...）、地区（US、EU、Asia...）或不同的应用程序类型（如果您必须在为移动客户端提供服务时配置服务器）而不是网络或桌面）。

通常，人们要么手动维护配置文件（如您所述），这容易出错且不安全。或者使用 Pedro 提到的构建脚本在配置文件中“偷看”和“戳”出正确的值。这种方法还意味着对于影响配置的每个代码更改，脚本也应该更改，这是不理想的。调试和测试这些脚本（无论它们使用什么语言）通常很困难，如果不是不可能的话。

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

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

于 2012-01-10T11:21:49.387 回答