2

我们目前的建造过程

我们是一个小型开发团队（2 到 4 人，具体取决于项目），他们目前使用 Phing 在上线之前将代码部署到暂存环境。我们将代码保存在 SVN 存储库中，主干保存当前的活动开发，并且在某些时候，我们会创建我们测试的分支，然后（如果成功）标记并导出到暂存环境。如果那里一切顺利，我们最终将它们部署在生产服务器中。动作是高度自动化的，但总是由人工干预触发。

疑点

我们现在想在流程中引入持续集成（与 Hudson 一起）；不幸的是，我们对活动同步有一些疑问，因为我们担心 CI 会在某种程度上干扰我们的构建过程并导致某些问题。

考虑到自动化 CI 循环具有一定频率的自动执行操作，我们看到两种可能的“集成”情况，每种情况都有其自身的问题：

  1. 案例 A：每个 CI 循环都会产生一个具有自己名称的新分支；我们确实使用这样的名称来手动（通过现在发生的 phing）将代码从 SVN 导出到暂存环境。我在这里看到的问题是（除非采取了特定的对策 - 删除 IE）我们拥有的分支数量很容易失控（假设我们经常提交，这样我们每 N 分钟就有一个新的构建/分支） .

  2. 案例 B：每个 CI 循环都会创建一个名为“current”的新分支，然后仅当我们手动决定将其导出到 staging 时才使用唯一名称对其进行标记；无论如何，只要下一个 CI 周期开始，当前分支就会被删除。我们在这里看到的问题是，当有人将“当前”分支标记/导出到暂存时，可能会启动一个新周期，从而创建不一致的构建（但也许在这里我太悲观了，因为我承认我不知道SVN 是否提供了一些针对此的内置保护）。

说了这么多，我想知道是否有类似经历的人可以这么好心地给我们一些关于这个主题的提示，因为上面描述的方法都没有让我们完全满意。

有没有什么重要的事情我们在整体上完全忽略了？感谢您的关注和（提前）您的帮助！

4

2 回答 2

2

在这两个选项中，您都从“每个 CI 周期产生一个新分支”开始。不要那样做。您希望将分支数量保持在最低限度并始终处于控制之下（手动创建），以避免您的项目变得一团糟。决定主线中的开发是否准备好并且您可以生成发布候选（主干的分支）并非易事。

CI 周期由代码中的更改触发，以确保这些更改的集成不会破坏应用程序。因此，您宁愿在 Hudson 中为每个活跃的开发流设置一个项目，一个用于主线，一个用于代表生产版本（用于修复错误）的分支，最后一个用于 RC。

Martin Fowler 关于持续集成的文章是关于 CI 实施的原因和方式的优秀指南。

于 2010-06-01T19:36:48.440 回答
2

我们在项目中使用的一种方法是仅在代码更改时运行 CI 构建。这可以在您的 SVN 上配置为提交后挂钩。然后，您可以通过经过身份验证的 URL 在 HUDSON 中远程触发构建。我看到的问题是，由于必须创建工作，除非您的构建系统支持它，否则 hudson 无法确定 repo 上有一个新分支并为此创建一个工作。

于 2010-04-16T06:55:57.040 回答