我们当前的构建流程
我们是一个小型开发团队(2 到 4 人，具体取决于项目)，目前在上线之前使用 Phing 将代码部署到暂存环境。我们将代码保存在 SVN 存储库中，其中主干保存当前活跃的开发，并且在某些时候，我们确实会创建测试分支，然后(如果成功)标记并导出到暂存环境。如果一切顺利，我们最终将它们部署在生产服务器中。 操作高度自动化，但总是由人为干预触发。
怀疑
我们现在想在此过程中引入持续集成(与 Hudson)；不幸的是，我们对事件同步有一些疑问，因为我们担心 CI 可能会在某种程度上干扰我们的构建过程并导致某些问题。
考虑到自动化 CI 周期具有一定的自动执行操作频率，我们看到“集成”有两种可能的情况，每种情况都有自己的问题:
情况 A:每个 CI 周期都会产生一个新的 有自己名称的分支机构；我们确实使用 这样的名称要手动(通过 phing 现在发生的情况)导出 从 SVN 到暂存的代码 环境。我在这里看到的问题是 (除非有具体的对策 采取 - IE删除)我们的分支数 有很容易失去控制(让我们 假设我们经常 promise ，这样我们 每年都有一个全新的构建/分支 N 分钟)。
情况 B:每个 CI 周期都会创建一个新的 名为“current”的分支，然后用 仅当我们手动时才具有唯一名称 决定将其导出到暂存区；这 当前分支，无论如何都是那么 下一个 CI 时立即删除 循环启动。我们看到的问题 这是一个新的周期可能会开始 当某人在的时候 标记/导出“当前” 分支到暂存，从而创建一个 构建不一致(但也许在这里 我只是太悲观了，因为我 承认我不知道SVN是否 提供一些内置保护 反对这一点)。
话虽如此，我想知道是否有类似经历的人可以给我们一些关于这个主题的提示，因为上面描述的方法看起来都不能让我们完全满意。
是否有一些重要的事情我们在整体图中完全遗漏了？ 感谢您的关注和(提前)您的帮助!
最佳答案
在这两个选项中，您都从“每个 CI 周期生成一个新分支”开始。 不要这样做。您希望将分支数量保持在最低限度并始终处于控制之下(手动创建)，以避免项目变得一团糟。主线中的开发是否已准备好以及您可以生成候选版本(主干的分支)的决定并不是微不足道的。
CI 周期由代码更改触发，以确保这些更改的集成不会破坏应用程序。因此，您宁愿在 Hudson 中为每个活跃的开发流建立一个项目，一个用于主线，一个用于代表生产版本(用于修复错误)的分支，最后一个用于 RC。
Martin Fowler's article about Continuous Integration是关于 CI 实现的原因和方式的优秀指南。
关于php - 如何将 CI (Hudson) 事件同步到现有的自动化构建流程(phing、svn)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2650187/