DevOps 流程:以小批量方式工作

在任何领域中,如果您很重视反馈循环或者希望从自己所做的决策中快速获得有用信息,都必须遵循以小批量方式工作的原则。采用小批量工作方式时,您不但可以通过快速测试假设条件了解特定改进措施能否产生预期效果,还可以在未达到预期效果的情况下采取纠正措施或重新审视假设条件。本文中的说明适用于包括组织转型和流程改进在内的任何类型的变更,但主要侧重于软件交付。

小批量工作方式已成为精益产品管理的一部分。如果结合掌握价值流中的工作团队实验清晰了解客户反馈等功能,小批量工作方式可预测软件交付性能和组织绩效。

如果交付变更具有很高的固定成本,那么此时就需要采用大批量工作方式。在传统的分阶段软件开发方法中,从开发到测试或从测试到 IT 运营的交付会涉及整个发布流程,也就是说,需要由数十人或数百人组成的团队进行数月的工作。采用这种传统方法时,收集有关某项变更的反馈可能需要数周或数月的时间。

相比之下,DevOps 做法利用跨职能团队和轻量级方法,使软件只需几分钟即可从开发环境推进到测试和运营环境,从而快速投入生产环境。但是,这种快速推进需要以小批量方式处理代码。

小批量工作方式具有很多优势:

  • 可让您更快速地获取有关变更的反馈,从而更轻松地对问题进行分类和修复。
  • 可提升工作效率和动力。
  • 可防止您的组织屈服于沉没成本谬论。

您可以在特性和产品级层应用小批量方法。举例来说,最简可行产品(英文简称为 MVP)是指产品的原型,它仅具备向人们有效展示该产品及其商业模式所需的特性。

持续交付以小批量工作为基础,并会尝试尽快获取版本控制中的所有变更。持续交付的目标是改变软件交付流程的经济性,使小批量工作方式具有可行性。这种方法可以为团队提供快速、全面的反馈,让他们得以改善自己的工作。

如何以小批量方式工作

当您规划新的特性时,可尝试将这些特性分解为若干可在短时间内独立完成的工作单元。我们建议确保每项特性或每批次工作都遵循下列 INVEST 原则这一敏捷概念:

  • 独立性。尽量使特定批次的工作独立于其他批次,让团队可以按任意顺序处理这些特定工作,并独立于其他批次的工作进行部署和验证。
  • 可协商性。每批次工作都是可迭代的,并且可以在收到反馈后重新进行协商。
  • 有价值。每批次工作都有一定的作用,并且都会为利益相关者带来价值。
  • 可估算性。各批次工作都可提供足够的相关信息,让您可以轻松估算范围。
  • 规模小。在 Sprint 期间,您应该能够以较短的时间增量(即数小时到数天)完成各批次工作。
  • 可测试性。每批次工作都可以按照用户期望的方式进行测试、监控和验证。

如果特性具有适当的规模,您可以将特性的开发工作拆分成更小的批次。这个过程可能很难完成,并且需要经验才能取得进展。理想情况下,您的开发者应该每天至少一次将多个小规模可发布变更整合到主干中。

为了实现此目标,关键在于在服务或 API 层(而不是界面层)开始进行开发。这样,您就可以向 API 添加一些最初对应用用户并不可用的特性,并将这些变更整合到主干中。您可以将这些变更发布到生产环境,而不提供给用户。这种方法称为“暗发布”,旨在使开发者能够签入已完成小批次的代码,而不能签入尚未完全完成的特性的代码。之后,您可以针对这些变更运行自动化测试,以此证明其行为符合预期。这样一来,团队就仍然可以高效工作,同时进行主干开发(而非长期特性分支开发)。

此外,您还可以利用特性开关(这是一个基于配置设置的条件语句)对变更进行暗发布。例如,您可以决定是否显示界面元素,或者是否启用服务逻辑。特性开关配置可以在部署或运行时读取。您可以使用这些配置设置在堆栈中进一步切换新代码的行为。您也可以使用类似技术(称为抽象分支)对系统进行大规模更改,同时继续开发和发布主干,而无需使用长期特性分支。

采用这种方法时,只有在各批次工作部署到生产环境中并且反馈流程已开始验证变更后,这些工作才能完成。反馈渠道的来源和形式多样,包括用户、系统监控、质量保证和自动化测试。您的目标是优化速度,从而缩短将变更交付到用户手中的周期时间。这样,您就能够以最快的速度验证您的假设条件。

小批量工作方式中常见的隐患

将工作分解成若干小批次时,通常存在以下两种隐患:

  • 未将工作分解成多个足够小的部分。您的首要任务是以有意义的方式分解工作。我们建议您提交与特性状态无关的代码,并确保各个特性的开发时间不超过数天。任何需要一周以上时间才能完成和签入的代码批次都违反了“规模小 (Small)”的原则。在整个开发过程中,您必须分析如何将想法分解为可迭代开发的增量,这一点至关重要。

  • 采用小批量工作方式,但在将各批次发送到下游进行测试或发布之前,对其进行重新整理。以这种方式重新整理工作会使您无法及时了解变更是否存在缺陷,以及您的用户和您的组织是否同意先构建这些变更。

减小工作批次规模的方法

将工作分割成若干只需数小时即可完成的小批次后,您通常可以在一小时内测试这些批次并将其部署到生产环境 (PDF)。关键在于应将工作分解为若干可快速开发的小规模特性,而不要在分支上开发复杂且不常发布的特性。

为了改善小批次开发的表现,请检查您的环境并确认满足以下条件:

  • 工作的分解方式支持团队更频繁地进行生产发布。
  • 开发者在将工作分解为可在数小时(而非数天)内完成的小规模变更方面拥有丰富的经验。

要成为小批量开发的专家,请确保您的所有开发团队都能满足这些条件。这一做法对于持续集成主干开发来说都是一个必不可少的条件。

衡量工作批次规模的方法

如果您了解持续集成监控,就应该能够大致描述出在系统和开发环境中适用于小批次开发的几种衡量方法。

  • 应用特性的分解方式支持频繁发布。可行的发布频率如何?各团队的发布节奏有何不同?生产延迟是否与规模较大的特性有关?
  • 应用特性的分解方式使开发者能够在一周或更短时间内完成工作。您可以在一周或更短时间内完成的特性占多大比例?哪些特性需要一周以上时间才能完成?您能否在特性完成之前提交并发布变更?
  • 已定义 MVP 并将其设定为团队目标。工作是否已分解为若干遵循 MVP 原则并可快速开发的特性,而不是多个复杂而冗长的流程?

您的衡量结果取决于以下几个方面:

  • 了解您组织的流程。
  • 制定减少浪费的目标。
  • 设法降低开发流程的复杂性。

后续步骤