Hudson CI 服务器显示稳定的“天气”，这很酷。它允许一个项目构建基于另一个项目的成功构建而开始。但是，您如何使第二个项目额外依赖于第一个项目的多个构建的稳定性？
具体来说，如果项目“integrate”与版本 8.3.4.1233 已成功构建和测试至少 8 次（连续成功），则项目“stable_deploy”只需启动以将版本提升为“稳定”。在那之前，它仍处于集成模式。
重要提示：对此的一个重要警告是，一组 Hudson 项目被用作处理每个新版本直至发布的“管道”。因此，一个项目可能连续成功构建了 8 次，但最新版本 8.3.4.1233 可能只是最近的 2 次构建。在此之前的版本可能是较早的版本。
我们愿意完全重组它，但管道的想法似乎大大减少了手动项目创建和删除的数量。有没有更好的方法来跟踪版本发布“管道”？特别是，由于对旧版本的修复或补丁，我们将在未来同时在此管道中拥有多个版本。除了为每个版本创建新的管道项目之外，我们还没有看到如何做到这一点，这确实很麻烦。
以下是一些背景细节：
TickZoom 应用程序有一些非常完整的单元测试，其中一些模拟实时交易环境。除此之外，TickZoom 还巧妙地利用并行化来利用多核计算机。不用说，在新版本的开发过程中，在集成测试过程中可能会出现稳定性问题，通过反复运行构建和自动测试会发现这些问题。连续 8 次干净地构建和测试的版本，加上经过用户实际测试的版本可以被视为“稳定”并升级到稳定分支。
我们的 Hudson 项目如下所示：
test - 仅用于测试构建，零用户可见性。integration_deploy - 促进测试项目构建以集成分支，并使其可供公众用于 UA 测试。集成 - 重复构建集成分支以确定它是否足够稳定以提升到稳定分支。这会在每晚每小时运行构建和测试。stable_deploy - 将集成项目构建提升到稳定分支，并将其公开给想要最新和最好的用户。stable - 每晚构建一次 stable 分支。经过 2 周的成功构建（14 个构建）后，它可以进入“候选发布版”。
依此类推......它继续“发布候选”，然后是“发布”。