我想弄清楚的问题是，最好是将构建文件与源代码（即主干和分支）保持在一起，还是在某个单独的位置（显然仍在SCM下）。
问题：（在阅读文本的其余部分时请记住）构建文件，确保在任何时候（以维护费用为代价）重新构建分支，或确保分支可重建性最新的错误修正/改进（构建过程）很快被多个分支和不同的项目使用（以与旧分支的向后兼容为代价）
我们正在构建什么或使用什么技术并不重要，只是为了完整性：使用SVN进行移动应用程序，使用ANT构建/打包，使用SVN进行SCM。
Buildfile =构建器/编译器/打包程序从源代码编译和打包应用程序的说明。
这就是我们现在所拥有的。 Ant的build.xml与SVN中的主代码一起存储。许多其他支持“打包”文件（Apple的配置文件和证书）也存储在那里。
优点：
从DEV角度进行单一结账。当开发人员检查主干或其中一个分支时，构建文件就在那里。他们不需要在别处搜索它。结帐后只需一个简单的ant build即可。
如果在主干上完成对构建/打包过程的更改，需要在代码中进行一些重组（不同的文件位置，支持编译器常量等），我不必担心破坏现有分支，因为每个分支都会获得它自己的修订。
缺点：
当在主干上完成对构建/打包过程的更改以改进过程并修复错误时，我现在需要担心将这些更改合并到所有活动分支，这意味着必须跟踪所有dev /除了发布分支之外还有功能分支。
无法重复使用。技术上相同的项目，只需要对构建文件进行一些切换/属性更改，就应该能够使用相同的构建文件。但是因为它们分布在多个项目位置（除了多个分支，从上面开始），进行影响所有这些位置的通用改进变成了一场噩梦。主要是因为无论如何，这些文件在这里和那里最终只有很少的“补丁工作”，并且最终会出现冲突的合并以及如此略微不同的流程，如果不将其中一个项目搁置就无法解决并修改该过程以“赶上”另一个。
为了解决上一个场景在重用单个文件方面的缺点，并避免在整个地方进行过多的小修复，我一直在考虑将构建文件保持独立。在主干，分支机构和其他类似项目之间共享。
优点：
缺点：
DEV没有“单一结账”（但可以通过 svn externals 或其他链接解决方案解决
打破旧/现有版本。由于现在只有一个版本的文件，因此引入需要代码重构的改进将使其与旧分支不兼容。当需要重建旧分支时（对已发布的软件进行紧急修复），构建文件将不再起作用。是的，但是通过获取文件的先前版本可以解决这个问题：
所以对我而言，让我的生活更轻松，只维护一个文件以进行错误修正和改进，从而确保项目使用相同的流程，构建过程的最新错误修正等，或者让开发人员的生活更轻松，这是一个折腾。提供单点结账，并确保分支“稳定性/可重建性”，因为与分支机构签入的构建文件可以保证与该分支一起使用。
这有适当的方法吗？这是什么方法？我接近这个错误吗？
答案 0 :(得分：0)
我建议您每次构建时使用版本号标记代码。如果您想要回滚到修订版，可以始终从该修订版的标记创建一个新分支，并使用该修订版中的build.xml
您还可以将所有人工制品发布到名为目录的修订版中。如果要回滚，可以使用此目录中的人工制品，而不是再次完成构建过程。
您的构建文件应始终是代码的一部分。这样，开发人员可以将他/她的代码签出到IDE中，并从那里开始构建以进行本地测试。
如果您具有与每个环境不同的env相关配置，则应将其分离为部署代码时使用的部署配置。
如果要跨项目重用构建文件，可以使用在开始构建之前获取的宏来创建主构建文件。如果要覆盖默认行为，则唯一需要做的是覆盖本地项目中的宏