Hudson分支的推广可以基于项目的稳定性吗？

Question

Hudson CI服务器显示稳定的“天气”，这是很酷的。它允许一个项目的构建在成功构建另一个项目的基础上启动。但是，如何才能使次要项目额外依赖于第一个项目多个构建的稳定性呢？

具体地说，如果与版本8.3.4.1233的项目“集成”已经成功构建和测试了至少8次--连续8次，那么项目"stable_deploy“只需要启动就可以将一个版本提升到”稳定“。在此之前，它仍处于集成模式。

重要:一个重要的警告是，一个单独的Hudson项目集被用作处理每个新版本到发布的“管道”。因此，一个项目可能在一次滚动中成功构建了8次，但最新版本8.3.4.1233可能只是最近的2次构建。在此之前的构建可能是更早的版本。

我们对完全重组这一点持开放态度，但管道的想法似乎大大减少了手动创建和删除项目的数量。有没有更好的方法来跟踪版本发布“流水线”？特别是，由于对旧版本的修复或补丁，未来我们将在此管道中同时使用多个版本。我们还没有看到如何做到这一点，除了为每个版本创建新的管道项目，这是一个真正的麻烦。

以下是一些背景信息：

TickZoom应用程序有一些非常完整的单元测试，其中一些模拟了实时交易环境。除此之外，TickZoom还详细地使用了并行化来利用多核计算机。不用说，在新版本的开发期间，在集成测试期间可能会出现稳定性问题，这些问题会通过重复运行构建和自动测试而暴露出来。一个连续8次干净地构建和测试的版本，没有变化，再加上经过用户的一些真实测试，可以被认为是“稳定的”，并提升到稳定分支。

我们的Hudson项目如下所示：

仅用于测试构建的测试，零用户可见性。integrate_deploy -促进测试项目构建以集成分支，并使其可用于UA测试。集成-重复构建集成分支，以确定它是否足够稳定，可以升级到稳定分支。它每晚每小时运行一次构建和测试。stable_deploy -将集成项目构建提升到稳定分支，并将其公开给想要最新最好的用户。稳定-每晚构建一次稳定分支。在成功构建2周(14个构建)之后，它可以转到"release candidate“。

以此类推。接下来是"release candidate“，然后是"release”。

Answer 1

答案是为软件的每个新的次要版本创建一个单独的作业管道。

所以他们会是这样的。

integrate_0.8.3 stable_0.8.3 candidate_0.8.3 release_0.8.3

我们将使用Hudson API通过脚本为每个新版本生成作业。

升级不能完全自动化，因为除了稳定构建之外的其他因素，比如用户报告的错误，可能会延迟版本通过管道的移动。

诚心诚意，韦恩

Answer 2

我可以看到通过让多个连续的构建成功而没有错误来证明稳定性的意义，但我建议使用一种稍微不同的方法来使事情变得更简单。不要试图聚合多个构建的结果来确定您是否将最新的构建提升到稳定分支，而是针对相同的构建运行测试8次；您可以通过向测试添加重复计数参数来实现这一点，或者在Hudson作业设置中多次重复测试步骤。

如果每次构建都能干净地通过，那么在将构建提升到稳定分支之前，您可以使用它作为网关将构建发送给用户进行“真实世界”测试。

这有几个优点；它使Hudson设置根据您的请求变得更加简单，而且它使您对构建的稳定性更有信心，因为您将针对相同的代码库多次运行测试，而不是每次针对不同的代码库运行测试。

Answer 3

我猜你要么在hudson之外实现一些解决方案，生成Hudson中使用的触发器文件，要么用你公司的特定规则扩展促销插件。