UQDS:一个将质量放在首位的软件开发流程

终极质量开发系统是 Twisted 软件项目发布稳定可靠代码的关键。
406 位读者喜欢这篇文章。
GitHub launches Open Source Friday 

Opensource.com

终极质量开发系统 (UQDS) 是一种软件开发流程,它为如何使用分支、工单和代码审查提供了清晰的指导方针。它由 Divmod 在十多年前发明,并被 Twisted 采用,Twisted 是一个 Python 事件驱动框架,它是 HipChat 等流行的商业平台以及 Scrapy (一个网络爬虫) 等开源项目的基础。

可惜的是,Divmod 已经不复存在了——它像许多初创公司一样走向了衰落。幸运的是,由于其许多产品都是开源的,它的遗产得以延续。

当 Twisted 还是一个年轻的项目时,对于代码何时“足够好”可以投入使用,并没有明确的流程。结果,虽然有些部分经过高度润色且可靠,但另一些部分则是 alpha 质量的软件——无法区分哪些是哪些。UQDS 被设计为一个流程,以帮助一个存在明确质量挑战的现有项目在继续添加功能并变得更有用的同时,提高其质量。

UQDS 帮助 Twisted 项目从频繁出现回归错误,需要多个候选发布版本才能获得可工作版本,发展到如今拥有稳定可靠的声誉。

UQDS 的构建块

UQDS 由 Divmod 在 2006 年发明。当时,持续集成 (CI) 尚处于起步阶段,而允许轻松分支合并的现代版本控制系统几乎还只是概念验证。尽管 Divmod 没有今天的现代工具,但它整合了 CI、一些临时工具来使 Subversion 分支 工作,并对工作流程进行了大量思考。因此,UQDS 方法论应运而生。

UQDS 基于基本的构建块,每个构建块都有自己经过仔细考虑的最佳实践

  1. 工单
  2. 分支
  3. 测试
  4. 审查
  5. 没有例外

让我们更详细地了解一下每一个。

工单

在使用 UQDS 方法论的项目中,任何更改都必须附带工单才能进行。这创建了关于需要什么更改以及—更重要的是—为什么更改的书面记录。

  • 工单应定义清晰、可衡量的目标。
  • 只有当工单包含明确定义的目标时,才能开始处理工单。

分支

UQDS 中的分支与工单紧密耦合。每个分支必须解决一个完整的工单,不多也不少。如果一个分支解决的工单多于或少于一个,则意味着工单定义或分支存在问题。工单可能会被拆分或合并,或者分支被拆分和合并,直到达成一致。

强制每个分支不多也不少地处理一个工单—这对应于一个逻辑上可衡量的更改—使使用 UQDS 的项目能够对提交进行细粒度控制:可以还原单个更改,甚至可以以与提交顺序不同的顺序应用更改。这有助于项目维护稳定和干净的代码库。

测试

UQDS 依赖于各种自动化测试,包括单元测试、集成测试、回归测试和静态测试。为了使其工作,所有相关测试必须始终通过。未通过的测试必须修复,或者如果不再相关,则必须完全删除。

测试也与工单耦合。所有新工作都必须包含测试,以证明工单目标已完全实现。没有这个,无论工作看起来有多好,都不会被合并。

关注测试的一个副作用是,使用 UQDS 的项目可以声明支持的唯一平台是那些在 CI 框架中运行测试的平台—并且在该平台上通过测试是合并分支的条件。如果没有对支持平台的这种限制,项目的质量就不是终极的。

审查

虽然自动化测试对于 UQDS 确保的质量很重要,但该方法论永远不会忽视人为因素。每个分支提交都需要代码审查,并且每次审查都必须遵循非常严格的规则

  1. 每个提交都必须由作者以外的其他人审查。
  2. 首先用评论感谢贡献者的工作。
  3. 记录下贡献者做得特别好的地方 (例如,“这个变量名太完美了!”)。
  4. 记录下可以做得更好的地方 (例如,“这行代码可以添加注释来解释选择。”)。
  5. 最后给出明确的下一步指示,通常是 按原样合并修复并合并修复并提交重新审查

这些规则尊重贡献者的时间和努力,同时也增加了知识和想法的共享。明确的下一步指示使贡献者对如何取得进展有一个清晰的概念。

没有例外

在任何流程中,都很容易找到理由来说明为什么您可能需要稍微放宽规则,让这件事或那件事滑过系统。UQDS 最重要的基本构建块是没有例外。整个社区共同努力,确保规则不会被放宽,无论出于何种原因。

知道所有代码都已获得作者以外的其他人批准,代码具有完整的测试覆盖率,每个分支对应于一个工单,并且该工单经过深思熟虑且完整,这带来了一种安心感,即使是对于一个小的例外,也不值得冒险失去。目标是质量,而质量并非来自妥协。

UQDS 的缺点

虽然 UQDS 帮助 Twisted 成为一个高度稳定可靠的项目,但这种可靠性并非没有代价。我们很快发现,审查要求导致了审查提交的减速和积压,从而导致开发速度变慢。解决这个问题的方法不是通过取消 UQDS 来妥协质量;而是重新调整社区的优先事项,使审查提交成为为项目做出贡献的最重要方式之一。

为了帮助解决这个问题,社区在 Twisted IRC 频道 中开发了一个机器人,它将回复 review tickets 命令,并列出仍需要审查的工单列表。Twisted 审查队列 网站返回一个按优先级排序的待审查工单列表。最后,整个社区密切关注需要审查的工单数量。这已成为社区用来衡量项目健康状况的重要指标。

了解更多

了解 UQDS 的最佳方法是 加入 Twisted 社区 并亲身实践。如果您想了解更多关于该方法论以及它如何帮助您的项目达到高水平的可靠性和稳定性的信息,请查看 Twisted wiki 中的 UQDS 文档

标签
Moshe sitting down, head slightly to the side. His t-shirt has Guardians of the Galaxy silhoutes against a background of sound visualization bars.
Moshe 自 1998 年以来一直参与 Linux 社区,帮助举办 Linux “安装派对”。他自 1999 年以来一直在编写 Python 程序,并为核心 Python 解释器做出了贡献。Moshe 在 DevOps/SRE 这些术语出现之前就一直是 DevOps/SRE,他非常关心软件可靠性、构建可重现性以及其他此类事情。

评论已关闭。

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.