机器可以完成这项工作，一个关于 kubernetes 测试、CI 和自动化贡献者体验的故事

作者：Aaron Crickenberger（谷歌）和 Benjamin Elder（谷歌）

”大型项目有很多不那么令人兴奋，但却很辛苦的工作。比起辛苦工作，我们更重视把时间花在自动化重复性工作上，如果这项工作无法实现自动化，我们的文化就是承认并奖励所有类型的贡献。然而，英雄主义是不可持续的。“ - Kubernetes Community Values

像许多开源项目一样，Kubernetes 托管在 GitHub 上。 如果项目位于在开发人员已经工作的地方，使用的开发人员已经知道的工具和流程，那么参与的障碍将是最低的。 因此，该项目完全接受了这项服务：它是我们工作流程，问题跟踪，文档，博客平台，团队结构等的基础。

这个策略奏效了。 它运作良好，以至于该项目迅速超越了其贡献者的人类能力。 接下来是一次令人难以置信的自动化和创新之旅。 我们不仅需要在飞行途中重建我们的飞机而不会崩溃，我们需要将其转换为火箭飞船并发射到轨道。 我们需要机器来完成这项工作。

工作

最初，我们关注的事实是，我们需要支持复杂的分布式系统（如 Kubernetes）所要求的大量测试。 真实世界中的故障场景必须通过端到端（e2e）测试来执行，确保正确的功能。 不幸的是，e2e 测试容易受到薄片（随机故障）的影响，并且需要花费一个小时到一天才能完成。

进一步的经验揭示了机器可以为我们工作的其他领域：

• Pull Request 工作流程
  • 贡献者是否签署了我们的 CLA？
  • Pull Request 通过测试吗？
  • Pull Request 可以合并吗？
  • 合并提交是否通过了测试？
• 鉴别分类
  • 谁应该审查 Pull Request？
  • 是否有足够的信息将问题发送给合适的人？
  • 问题是否依旧存在？
• 项目健康
  • 项目中发生了什么？
  • 我们应该注意什么？

当我们开发自动化来改善我们的情况时，我们遵循了以下几个指导原则：

• 遵循适用于 Kubernetes 的推送/拉取控制循环模式
• 首选无状态松散耦合服务
• 更倾向于授权整个社区权利，而不是赋予少数核心贡献者权力
• 做好自己的事，而不要重新造轮子

了解 Prow

这促使我们创建 Prow 作为我们自动化的核心组件。 Prow有点像 If This, Then That 用于 GitHub 事件， 内置 commands， plugins， 和实用程序。 我们在 Kubernetes 之上建立了 Prow，让我们不必担心资源管理和日程安排，并确保更愉快的运营体验。

Prow 让我们做以下事情：

• 允许我们的社区通过评论诸如“/priority critical-urgent”，“/assign mary”或“/close”之类的命令对 issues/Pull Requests 进行分类
• 根据用户更改的代码数量或创建的文件自动标记 Pull Requests
• 标出长时间保持不活动状态 issues/Pull Requests
• 自动合并符合我们PR工作流程要求的 Pull Requests
• 运行定义为Knative Builds的 Kubernetes Pods或 Jenkins jobs的 CI 作业
• 实施组织范围和重构 GitHub 仓库策略，如Knative Builds和GitHub labels

Prow最初由构建 Google Kubernetes Engine 的工程效率团队开发，并由 Kubernetes SIG Testing 的多个成员积极贡献。 Prow 已被其他几个开源项目采用，包括 Istio，JetStack，Knative 和 OpenShift。 Getting started with Prow需要一个 Kubernetes 集群和 kubectl apply starter.yaml（在 Kubernetes 集群上运行 pod）。

一旦我们安装了 Prow，我们就开始遇到其他的问题，因此需要额外的工具以支持 Kubernetes 所需的规模测试，包括：

• Boskos: 管理池中的作业资源（例如 GCP 项目），检查它们是否有工作并自动清理它们 (with monitoring)
• ghProxy: 优化用于 GitHub API 的反向代理 HTTP 缓存，以确保我们的令牌使用不会达到 API 限制 (with monitoring)
• Greenhouse: 允许我们使用远程 bazel 缓存为 Pull requests 提供更快的构建和测试结果 (with monitoring)
• Splice: 允许我们批量测试和合并 Pull requests，确保我们的合并速度不仅限于我们的测试速度
• Tide: 允许我们合并通过 GitHub 查询选择的 Pull requests，而不是在队列中排序，允许显着更高合并速度与拼接一起

##　关注项目健康状况

随着工作流自动化的实施，我们将注意力转向了项目健康。我们选择使用 Google Cloud Storage (GCS)作为所有测试数据的真实来源，允许我们依赖已建立的基础设施，并允许社区贡献结果。然后，我们构建了各种工具来帮助个人和整个项目理解这些数据，包括：

• Gubernator: 显示给定 Pull Request 的结果和测试历史
• Kettle: 将数据从 GCS 传输到可公开访问的 bigquery 数据集
• PR dashboard: 一个工作流程识别仪表板，允许参与者了解哪些 Pull Request 需要注意以及为什么
• Triage: 识别所有作业和测试中发生的常见故障
• Testgrid: 显示所有运行中给定作业的测试结果，汇总各组作业的测试结果

我们与云计算本地计算基金会（CNCF）联系，开发 DevStats，以便从我们的 GitHub 活动中收集见解，例如：

• Which prow commands are people most actively using
• PR reviews by contributor over time
• Time spent in each phase of our PR workflow

Into the Beyond

今天，Kubernetes 项目跨越了5个组织125个仓库。有31个特殊利益集团和10个工作组在项目内协调发展。在过去的一年里，该项目有 来自13800多名独立开发人员的参与。

在任何给定的工作日，我们的 Prow 实例运行超过10,000个 CI 工作; 从2017年3月到2018年3月，它有430万个工作岗位。 这些工作中的大多数涉及建立整个 Kubernetes 集群，并使用真实场景来实施它。 它们使我们能够确保所有受支持的 Kubernetes 版本跨云提供商，容器引擎和网络插件工作。 他们确保最新版本的 Kubernetes 能够启用各种可选功能，安全升级，满足性能要求，并跨架构工作。

今天来自CNCF的公告 - 注意到 Google Cloud 有开始将 Kubernetes 项目的云资源的所有权和管理权转让给 CNCF 社区贡献者，我们很高兴能够开始另一个旅程。 允许项目基础设施由贡献者社区拥有和运营，遵循对项目其余部分有效的相同开放治理模型。 听起来令人兴奋。 请来 kubernetes.slack.com 上的 #sig-testing on kubernetes.slack.com 与我们联系。

想了解更多？ 快来看看这些资源：

• Prow: Testing the way to Kubernetes Next
• Automation and the Kubernetes Contributor Experience

• ←上一页
下一页→