问题描述
在使用Git进行源代码控制、MSBuild进行构建、以及Jenkins进行持续集成的工作中，有一个关于存储MSBuild XML配置文件的问题。用户的Git仓库会有不同的分支，用于产品的不同阶段（开发、QA、发布）。
用户的问题是，应该在哪里存储MSBuild XML配置文件？如果将它与产品代码一起检入，比如在开发分支中，当有一个特性分支时，文件在从父分支合并时会被合并。所以这不是一个选项。
用户还希望构建配置与产品版本保持一致。因此，build.xml 将从开发分支->QA分支->发布分支传递。
用户想知道其他人是如何处理这个问题的。
解决方案
请注意以下操作可能涉及版本差异和根据实际情况进行修改。
方案1：与产品代码存储在同一仓库
通常，构建配置应该与产品代码保持一致，所以应该将其存储在与产品代码相同的Git仓库中。虽然文件在从父分支合并时可能会被合并，但通常这是一个简单的（空/快进）合并，只有当父分支中的msbuild xml文件没有更改时。如果合并不是简单的合并，这意味着父分支中的构建过程发生了变化，子分支也必须考虑这些变化，因为子分支还会捎带这些构建变化所带来的代码更新。换句话说，msbuild xml合并在这种情况下是必需的，以避免构建中断。
方案2：使用环境变量实现动态配置
另一种方法是将应用程序设计成能够读取系统环境变量的动态模式（例如，ENV=qa、ENV=beta或ENV=prod），然后为每个环境维护不同的属性文件，而构建.xml文件保持静态（仅引用变量）。这种方法有一个缺点，就是每次添加新环境时，都会在代码中添加一个新的属性文件。
方案3：分离配置与代码
在这种方法中，所有依赖资源（如数据库端点/凭证、主机名、电子邮件服务器和凭证等）都存储在系统环境变量或服务启动变量中，例如，在JVM中使用 -D 参数，然后使用配置管理工具（如Ansible、Salt、Chef）来维护所有配置，并在构建过程中使用这些配置。这样可以将平台代码与配置/依赖资源分离，使代码能够在不依赖于环境的情况下进行新功能的开发。
评论与补充
- 对于需要隔离文件的问题，可以使用Git的
.gitignore文件（https://help.github.com/articles/ignoring-files/）来忽略构建文件的更改。不过，正如上述建议，你需要开始实施环境变量，这是一种动态且可扩展的方法。 - 方案2中的环境变量的确是一个有效的方法，但我希望尽量减少在Jenkins等工具中设置变量的代码量。Perforce 使用了隔离文件的方法，我从那里得到了启发，而GitHub 通过CODEOWNERS文件实现了类似的功能。至于方案3，我目前正在尝试这个路线，我在一个专门的仓库中放置了我的 build.xml 文件（如
dev-ops_repo\QA-build\build.xml），但似乎这种方式在大规模应用时可能不太合适。