在 GitHub 上利用 Jenkins 获取不同的反馈
| 这是由edX工程经理Ben Patterson撰写的客座博文。 |
从篮子里挑一个梨很简单，你可以把它拿在手里，感受它的重量，也许轻轻捏一下，观察它的颜色，仔细看看是否有任何瘀伤。如果我们拥有的唯一信息是一张从一个角度拍摄的照片，我们就不得不进行一些有根据的猜测。 
作为开发人员，我们没有照片；我们得到一个绿色的对勾或一个红色的叉。我们用它来决定是否需要换挡，回到我们最近提交的拉取请求。在edX，我们利用Jenkins的一些功能，这些功能可以为GitHub拉取请求提供更精细的信息，并使这个决定不再是猜测。
多个上下文可用时报告
我们平台上的拉取请求从几个角度进行评估：静态代码分析（包括代码风格检查和安全审计）、JavaScript单元测试、Python单元测试、验收测试和可访问性测试。利用一系列插件，包括GitHub Pull Request Builder插件，我们将更直接的反馈交到贡献者手中，以便他/她能够快速决定需要进行多少挖掘工作。
例如，如果我调整了我的分支，并且知道还有更多的需求即将到来，那么我可能不太担心通过代码风格检查器；然而，如果我的单元测试失败了，我可能遇到了一个需要解决的问题，无论新的需求何时到来。时机也很重要。拆分上下文意味着我们可以并行运行测试并更快地报告结果。
开发人员可以重新运行特定上下文
有时反馈机制会失败。通常是测试中的不稳定条件或测试设置问题。（解决不稳定性是另一个话题，我在这里就不讨论了。为了这篇博文的目的，请接受系统会失败的事实。）工程师们拥有重新运行特定上下文的功能，这些功能也通过PR插件提供。例如，开发人员可以输入“jenkins run bokchoy”来重新运行验收测试。开发人员也可以输入“jenkins run all”来重新运行所有测试。这些短语是在GitHub Pull Request Builder配置中设置的。
我们的工具团队更容易找到更精细的数据
拆分上下文也为我们的工具团队提供了重要的数据点，以帮助突出显示不稳定的测试、反馈时间和其他有助于组织确定优先级的指标。我们使用日志聚合器（在我们这里是Splunk）来生成有价值的报告，例如这份报告。
我可以继续说下去！简而言之，我们有直观的方式来分配我们的测试，这不仅是为了优化获取构建结果的总时间，也是为了使开发人员的体验更加用户友好。
|
Ben将在9月份的 Jenkins World 上 演示 更多关于这个主题的内容，使用代码 |