如何将 CI (Hudson) 活动同步到现有的自动化构建流程（phing、svn）？
我们当前的构建流程
我们是一个由开发人员组成的小团队（2 到 4 人，具体取决于项目），他们目前在上线之前使用 Phing 将代码部署到暂存环境。我们将代码保存在 SVN 存储库中，其中主干保存当前活跃的开发，并且在某些时候，我们确实会创建测试分支，然后（如果成功）标记并导出到暂存环境。如果一切顺利，我们最终将它们部署在生产服务器中。 操作是高度自动化的，但总是由人为干预触发。
疑虑
我们现在想在此过程中引入持续集成（与 Hudson）；不幸的是，我们对活动同步有一些疑问，因为我们担心 CI 可能会在某种程度上干扰我们的构建过程并导致某些问题。
考虑到自动化 CI 周期具有一定的自动执行操作频率，我们看到“集成”有 2 种可能的情况，每种情况都有自己的问题：
情况 A：每个 CI 周期都会产生一个新的 有自己名称的分支机构；我们确实使用 这样的名称要手动（通过 phing 现在发生的情况）导出 从 SVN 到暂存的代码 环境。我在这里看到的问题是 （除非有具体的对策 采取 - IE删除）我们的分支数量 有很容易失去控制（让我们 假设我们经常承诺，这样我们 每年都有一个全新的构建/分支 N 分钟）。
情况 B：每个 CI 周期都会创建一个新的 名为“current”的分支，然后用 仅当我们手动时才具有唯一名称 决定将其导出到暂存区；这 当前分支，无论如何都是那么 下一个 CI 时立即删除 循环启动。我们看到的问题 这是一个新的周期可能会开始 当某人在的时候 标记/导出“当前” 分支到暂存，从而创建一个 构建不一致（但也许在这里 我只是太悲观了，因为我 承认我不知道SVN是否 提供一些内置保护 情况
话虽如此，我想知道是否有类似经历的人能好心地给我们一些关于这个主题的提示，因为上面描述的方法看起来都不能让我们完全满意。
是否有一些重要的事情我们在整体图中完全遗漏了？ 感谢您的关注& （提前）寻求您的帮助！
OUR CURRENT BUILD PROCESS
We're a small team of developers (2 to 4 people depending on project) who currently use Phing to deploy code to a staging environment, before going live. We keep our code in a SVN repo, where the trunk holds current active development and, at certain times, we do make branches that we test and then (if successful), tag and export to the staging env. If everything goes well there too, we finally deploy'em in production servers.
Actions are highly automated, but always triggered by human intervention.
THE DOUBT
We'd now like to introduce Continuous Integration (with Hudson) in the process; unfortunately we have a few doubts about activity syncing, since we're afraid that CI could somewhat interfere with our build process and cause certain problems.
Considering that an automated CI cycle has a certain frequency of automatically executed actions, we see 2 possible cases for "integration", each with its own problems:
Case A: each CI cycle produces a new
branch with its own name; we do use
such a name to manually (through
phing as it happens now) export the
code from the SVN to the staging
env. The problem I see here is that
(unless specific countermeasures are
taken - IE deletion) the number of branches we
have can easily grow out of control (let's
suppose we commit often, so that we
have a fresh new build/branch every
N minutes).Case B: each CI cycle creates a new
branch named 'current', which is then tagged with a
unique name only when we manually
decide to export it to staging; the
current branch, at any case is then
deleted, as soon as the next CI
cycle starts up. The problem we see
here is that a new cycle could kick
in while someone is
tagging/exporting the 'current'
branch to staging thus creating an
inconsistent build (but maybe here
I'm just too pessimist, since I
confess I don't know whether SVN
offers some built-in protection
against this).
With all this being said, I was wondering if anyone with similar experiences could be so kind to give us some hints on the subject, since none of the approaches depicted above looks completely satisfing to us.
Is there something important we just completely left off in the overall picture?
Thanks for your attention & (in advance) for your help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在这两个选项中，您都从“每个 CI 周期生成一个新分支”开始。 不要这样做。您希望将分支数量保持在最低限度并始终处于控制之下（手动创建），以避免项目变得一团糟。主线中的开发是否已准备好以及您可以生成候选版本（主干的分支）的决定并不是微不足道的。
CI 周期由代码中的更改触发，以确保这些更改的集成不会破坏应用程序。因此，您宁愿在 Hudson 中为每个活跃的开发流建立一个项目，一个用于主线，一个用于代表生产版本（用于修复错误）的分支，最后一个用于 RC。
Martin Fowler 关于持续集成的文章是关于 CI 实施的原因和方式的优秀指南。
In both options you start with "each CI cycle produces a new branch". Don't do that. You want to keep your number of branches to the minimum and always under control (manually created) to avoid that your project becomes a mess. The decision of whether the development in the mainline is ready and you can produce a release candidate (branch from the trunk) is not trivial.
CI cycles are triggered by changes in the code to ensure that the integration of those changes doesn't break the application. Therefore, you'd rather set up a project in Hudson for each active stream of development, this is, one for the mainline, one for the branch that represents the production version (for bug-fixing) and eventually one for the RC.
Martin Fowler's article about Continuous Integration is an excellent guide to the whys and hows of CI implementation.
我们在项目中使用的方法是仅在代码发生更改时才运行 CI 构建。这可以在 SVN 上配置为提交后挂钩。然后，您可以通过经过身份验证的 URL 远程触发 HUDSON 中的构建。但我看到的问题是，由于必须创建作业，除非您的构建系统支持它，否则 hudson 无法确定存储库上有一个新分支并为其创建作业。
An approach we used in our project was to run CI builds only when there was a code change. This can be configured on your SVN as a post commit hook. You can then remotely trigger builds in HUDSON via an authenticated URL. Problem I see though is that since jobs have to be created, unless your build system supports it, there is no way for hudson to figure out there is a new branch on the repo and create a job for that.