Athena:来自 Dropbox 的自动化构建监控工具

阅读数:4888 2019 年 7 月 4 日

Dropbox 每天会进行近 35,000 次构建,执行数百万个自动化测试用例。其中有一些测试可能会由于代码变更而执行失败,有一些执行失败的测试用例无法重现。因为 Dropbox 的测试规模很大,手动禁用失败的测试用例、回滚错误的代码提交以及通知测试所有者是很困难的。于是,Dropbox 开发了 Athena ,目的是为了自动化这些操作。Athena 可以将测试的失败用例通知给测试所有者,并检测和隔离失败的测试。它不会回滚错误的代码提交。

代码提交从基本的“预提交”测试开始,与主分支合并后进行“后提交”测试。后提交测试的成本比较高,包括 UI 和端到端测试。这一类测试会因为时间、日期和基础设施等环境因素发生失败,也有可能会因为并发性和随机数生成等代码固有特点而发生失败。Dropbox 之前有一个轮班团队负责回滚这些变更。InfoQ 联系了 Dropbox 的软件工程师 Utsav Shah,了解更多有关 Athena 的细节。

Athena 使用一种多步骤算法来确定一个测试用例是否存在问题。在一个周期内失败多次的后提交测试将被标记,并且允许代码通过。失败的测试将继续运行,以便确定失败是因为故障还是因为糟糕的代码导致的。Athena 还可以指出导致测试失败的代码提交位置。该系统通过自动隔离这类测试减少了 Dropbox 的运行开销。Shah 指出,Athena 被用来“监控 Dropbox 所有服务(后端、前端)的大部分测试,不过还没有被用来监控桌面或移动应用程序的测试。”

Dropbox 使用了持续集成(CI),尽管不同服务的部署策略不同。Shah 表示:

Dropbox 的后端服务由很多特定团队负责,还有一个主要的 Web 应用程序在支撑 dropbox.com 。我们要求所有相关的测试用例都是绿色的,非活动站点 / 实验性服务除外。一些服务所有者选择了持续部署,而另一些则喜欢手动部署。

Athena 提供了一个用户界面用来监控服务的状态,为开发者提供可见性,Shah 解释说:

我们显示每个测试用例的进度指标,以及它们基于不同代码提交的执行结果。每个测试用例都有一个对应的消息,指出哪个代码提交处于平分线状态,以及可能会导致测试失败的下界和上界。如果进度紧急,他们可以自己捕获并解决问题。

那么如何监控 Athena 系统呢?Shah 说,在这方面需要做更多的工作:

我们有一组单元测试,它们使用内部 CI 系统的一个虚拟版本来捕获业务逻辑中的回归问题,比如平分线中的 bug。我们针对 CI 系统进行集成测试,验证 API 的保证机制,这样可以捕获大多数问题。

Dropbox 的服务编排系统可以自动生成警报,捕捉很多基本问题。不过我们还没有对 Athena 进行实时监控。除非 CI 系统出现了问题,否则系统通常可以正常工作,我们大多数人都已经知道这种情况了。当某些上游 API 运行缓慢并且出现超时时,由于缺乏监控,有时会出问题,因此我们正在考虑添加一些基本警报来捕捉这些问题。

Athena 功能路线图中包含了自动回滚错误的代码提交和桌面测试。由于存在内部依赖关系,目前还没有将其开源的计划

原文链接

Athena: Automated Build Health Monitoring at Dropbox Engineering

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论