我在最近的几篇博文中讨论了Jenkins推广的构建插件，在谈到移动应用的QA过程和Beta测试分发时，我给出了一个简单的场景，说明如何使用它来帮助控制应用程序构建的测试生命周期。我碰巧和我的朋友，来自XebiaLabs的Andrew Phillips讨论过这个问题，他建议对该场景进行一些改进，我认为人们可能会喜欢看到，所以我重新编写了一个在线示例来说明这些想法。同时感谢川口大介的帮助和建议。顺便说一下，如果您对Jenkins的这个和其他企业级特性感兴趣，那么请与Andrew和我一起参加11月7日星期三举行的XebiaLabs和CloudBees联合网络研讨会：与Jenkins enterprise建立持续交付并部署它。****对于这个场景，我们有四个Jenkins作业，其中两个由开发人员"拥有"，另外两个由QA和Release Management"拥有"。开发人员将代码更改推送到Git存储库，并触发初始构建作业（buckoochess android）：此作业配置了一个构建升级（Release to QA），这取决于成功的构建/测试加上下游构建（buckoochess android matrix），后者检查与旧版android SDK的兼容性。就开发人员而言，他或她实际上只对初始应用构建/测试的结果感兴趣，但是在下游多配置测试构建完成之前，构建还没有准备好进行QA审查，因此升级状态显示如下：一旦下游矩阵构建成功运行（实际上我们会这样做）期望看到一系列其他测试，包括自动功能测试和触摸测试），该构建被自动升级，并准备好进行QA审查，升级状态现在看起来像这样这个：剩下的两个构建工作由QA和Release管理团队管理：它们由第二个构建提升（buckoochess QA批准）把关。第三个Jenkins作业（buckoochess android QA）是由发布到QA构建升级触发的，如这样：唯一的资格（在本例中）是由一个指定的QA评审员手动批准的，配置如下这是QA评审者通常会想查看单元测试结果，JUnit、Cobertura/Emma、Android Lint等工具报告的代码覆盖率和质量指标，或者Jenkins违规插件支持的许多代码质量工具中的一个或多个。许多用户可能更喜欢使用Jenkins来尽可能多地自动化质量和测试覆盖率检查，并且通常在接受构建之前设置必须达到的阈值。您可以在这里看到一个如何为Android构建配置此类报告的示例，在本博客中有更详细的描述。不管是哪种方式，buckoochess android QA作业都会这样显示它的升级状态，直到获得手动批准（通过登录Jenkins，查看构建并单击Accept）：一旦QA审阅者满意并且获得了手动批准，那么QA approval构建提升将运行，在这种情况下触发最终的构建作业（buckoochess android发行版）将批准的版本推到Zubhium进行beta测试发行，如之前的博客所述。布谷鸟象棋android QA作业的最终构建升级状态是现在：决赛难题的一部分是如何确保最终推送到Zubhium进行beta测试的构建是正确的：我们需要确保发布的应用程序归档包含原始buckoochess android构建的确切位置工作。配置的方法是使用Jenkins Copy Artifacts插件从buckoochess android项目获取.apk应用程序档案，使用permalink指定我们希望与最新版本关联的构建升级到QA构建升级。该配置如下所示：