【问题标题】：Buildfile with trunk/branch or separate带有主干/分支或单独的构建文件
【发布时间】：2014-06-18 08:53:57
【问题描述】：

我想弄清楚的问题是最好将构建文件与源代码一起保存，即主干和分支，还是在某个单独的位置（显然仍在 SCM 下）。

问题：（在阅读其余文本时要牢记）确保随时可重建分支的构建文件（以维护为代价），或确保最新的错误修复/改进（构建过程）被多个分支和不同的项目快速使用（以与旧分支的向后兼容性为代价）

我们正在构建什么或使用什么技术并不重要，只是为了完整性：制作移动应用程序，使用 ANT 构建/打包，使用 SVN 进行 SCM。

Buildfile = 构建器/编译器/打包器从源代码编译和打包应用程序的说明。

带有代码的构建文件

这就是我们现在所拥有的。 Ant 的build.xml 与SVN 中的主代码一起存储。许多其他支持“打包”文件（Apple 的配置文件和证书）也存储在那里。

优点：

缺点：

当在主干上完成构建/打包过程的更改以改进流程并修复错误时，我现在需要担心将这些更改合并到所有活动分支，这意味着必须跟踪所有开发/除了发布分支之外的特性分支。
没有可重用性。一个技术相同的项目，只需要对构建文件进行一些开关/属性更改，应该能够使用相同的构建文件。但是因为它们分布在多个项目位置（除了多个分支，如上所述），因此进行影响所有这些位置的通用改进成为一场噩梦。主要是因为无论如何，这些文件最终都会到处都有很少的“补丁工程”，最终会出现冲突的合并和非常细微的不同流程，如果不暂停其中一个项目就无法解决并修改该过程以“赶上”另一个过程。

构建文件与代码分开

为了解决先前方案在重用单个文件方面的缺点并避免到处进行过多的小修复，我正在考虑将构建文件分开。可在主干、分支和其他类似项目之间共享。

优点：

缺点：

DEV 没有“单一结帐”（但可以通过 svn externals 或其他链接解决方案解决
打破旧的/现有的构建。由于该文件现在只有一个版本，因此引入需要代码重组的改进将使其与旧分支不兼容。当需要重建旧分支时（紧急修复已发布的软件），构建文件将不再工作。是的，可以通过获取文件的先前版本来解决，但是：
1. 之前的哪个版本与这个分支一起工作并不是很明显
2. 旧版本可能缺少构建过程的一些其他关键错误修复。

所以对我来说，在让我的生活更轻松和只维护一个用于错误修复和改进的文件之间折腾，从而确保项目使用相同的流程、构建过程的最新错误修复等。或者通过以下方式让开发人员的生活更轻松提供单点签出，并确保分支“稳定性/可重建性”，因为通过分支签入的构建文件保证可以与该分支一起使用。

有没有合适的方法呢？什么是正确的方法？我是不是搞错了？

【问题讨论】：

我考虑了给定代码库的构建过程 part - 并认为它应该使用代码进行版本控制，但是 特定的 SCM 允许这样做。各种构建工具（rake、ant 等）可以帮助提取流程的细节，这意味着一般的“流程改进”是在外部处理的，并且已经作为某些 DSL 的一部分进行管理。

【解决方案1】：

我建议每次构建时都用版本号标记您的代码。如果您想回滚到修订版，您始终可以从该修订版的标签创建一个新分支并使用该修订版中的 build.xml

您还可以将所有工件发布到名为目录的修订版中。如果您想回滚，您可以只使用此目录中的人工制品，而无需再次执行构建过程。
您的构建文件应该始终是您代码的一部分。这样，开发人员可以将他/她的代码签出到 IDE 中，然后从那里开始构建以进行本地测试。
如果每个环境都有不同的 env 相关配置，则应将其分离为部署代码时使用的部署配置。
如果您想跨项目重复使用构建文件，您可以创建一个主构建文件，其中包含在开始构建之前获取的宏。如果您想覆盖默认行为，您唯一需要做的就是覆盖本地项目中的宏

【讨论】：