持续交付实践介绍

一天超过50次的持续交付

有一家月收入百万美元的互联网公司IMVU, 每天超过50次的部署代码到生产环境。 其员工Timothy Fitz发表的 文章 介绍了他们的网站服务的持续交付过程。支撑如此高频度部署的是其成熟的 自组织团队运作和高效的自动化测试与部署系统。每一次的代码提交都会触发测试, 跑完所有测试需要大约9分钟,代码部署到所有生产服务器需要大概6分钟。这个过程中 没有手工的测试。

那么质量是如何得到保障的?得益于测试套件的丰富与彻底。
  1. 整个测试套件包括一千多个文件,约一万四千个测试案例,串行执行大概需要4小时。分散到36台服务器并行测试,在理想状态下, 最短执行时间是 4*60/36, 即大约7分钟。
  2. 大约四分之一以上的测试时间是基于Selenium的页面模拟点击测试。剩下的时间是对服务 的功能测试和对代码模块的单元测试。
  3. 每次代码提交都要求跑所有的测试,而且要求错误率不得超过百万分之一次。 一天大概70次的全面测试,差不多意味着每天会遇到一次出错的情况。

持续交付意味着唯速度论? 既是,也不是。持续交付是在满足业务、市场、 质量要求的前提之下的越快越好。

如何开始持续交付?

Timothy Fitz在2012年底发表的 持续交付之路 介绍了如何开始持续交付, 用五个短句来描述:

  1. 开发人员尽早提交代码
  2. 每次提交都触发全面测试
  3. 自动化部署代码
  4. 生产环境监控与告警
  5. 出现错误要分析根本原因

持续集成与持续测试是持续交付的安全网和基本要求。作者文中推荐了Buildbot和Jenkins系统可用于支持 持续集成与测试。

而自动化部署工具应该具备试点能力,即将代码首先推送至小部分服务器,通过监控系统采集关键指标变化, 如何正常则推广至其他服务器,否则回退至旧版本,并通过告警系统通知相关人员进行处置。

第五点的重要性在于只有解决了根本原因,才能避免接下来多次地被同一个问题打断,达不到持续集成的效果。因此在开发任务清单中,除了新的功能外,要预留一部分时间和人员来解决这些问题。

文章开头所举例的持续交付并不是短时间内练成的。对于处于起步阶段的部门和团队而言, 可以从以下方面并行展开工作:

  1. 系统架构上应该以模块化和服务化为方向进行优化。 为模块和服务定义清晰的边界与接口,并梳理好各个部件的依赖关系。对开发人员而言,每次提交的改动 只在一个模块内。如果接口不变,那么影响就应该只在该接口以内;通过单元测试和相应的功能测试就可 以保证质量。如果接口改变,那么只需沿着依赖关系进行测试。通过这种方式来缩小回归测试范围。 语义化版本 可以帮助管理模块和服务的变化。
  2. 借鉴行为驱动开发 (BDD, Behavior Driven Development)和重构,补充单元测试。 可参考 单元测试模式 一书来学习做好单元测试。
  3. 手工测试人员与开发人员协作,将关键页面功能测试案例以自动化方式实现。
  4. 搭建持续集成环境, 提高测试的切分度与分布式并行执行,缩短全面测试所需时间。

大规模持续交付

持续交付关注的是单个产品全生命周期各个环节的自组织团队合作基础上的通过自动化加速交付速度。大规模持续交付的关键是在敏捷文化建设的基础上化整为零,按产品分为若干独立的小团队。

  1. 将大团队按业务分解为小团队
  2. 将单体大系统按业务分解为多个服务
  3. 一个团队负责一个服务的持续交付

持续交付与发布管理

持续交付的能力意味着团队能更快地、跟高质量地交付出可对外发布的软件或服务。而实际上以何种节奏交付哪些特性或改进组合的版本,这应该通过良好的交付管理来实现。比如说,网站后台不可见的小改进等,可以及时发布;而网站风格改版则是一个需要更多铺垫和过渡的过程。而客户端软件的发布管理则更明显。如非必要,很多人并不希望自己用得好好的软件总是提示新版本更新安装。因此,对于这些对客户有很明显影响的版本发布,需要做好和客户的交流。