只有产品顺利的发布给用户使用并获得良好反馈，整个团队的价值才有所体现。

引言

不知不觉，从 13 年接手 Google Doubleclick Sales Manager 到今年 7 月，4 年经历了 3 个 milestone, beta, GA 最终和 ad exchange 集成，一路走来，冷暖自知。
开始前做个调查，大家的项目发布周期是如何的，可以在回复里打数字：

1. 无固定发布周期
2. 每周发布
3. 每两周发布
4. 每月发布
5. 更长的发布周期

DSM 如何做发布

DSM 项目的发布情况，分为两大块：
常规的每周发布和新功能发布

常规的每周发布

• 上线的标准很简单，就是没有 P0/P1 的 bug

• 发布流程见下图

• 从 TAP(Test Automation Platform) 中自动获取最近三小时跑绿的 Changelist(CL),然后 build 新的版本
• 发布到 QA 环境
• QA 环境的自动化测试和手工测试
• 如果发现 P0/P1 的 bug，提交给开发修复，重新打补丁发布到 QA
• QA 环境验证 bug 后并 sign off 后发布到 Canary 环境
• Canary 环境停留 3 到 6 个小时，检查监控系统 eye3

• eye3 系统没有错误报告，最终上线

  • 下图是 Rapid(Release Automation Platform in DevInfra) 系统中一个完整的发布过程
  • Rapid 系统自动创建一个候选包
  • 同时运行 webdriver 自动化测试 (TAP 上一般执行 UT 和 ServiceTest, UI test 耗时单独跑)
  • 将候选包发布到 QA 环境，自动创建当周的 release bug 和 hotlist, 上到 QA 环境后运行 screen diff
  • QA 测试完成 Sign off 后陆续发布到 Canary 和 Prod 环境

新功能发布

• 每个新功能都有单独的功能开关
  

• 每个新功能都建立一个新功能类别的bug，让所有参与人有一个统一的沟通渠道，保证信息是同步的
  

• 新功能上线申请表，有若干检查项
  
  
  
  

• 如果新功能上线发现重大问题，可以快速的关闭

碰到的问题与解决

• TAP 可能不能获取到最近三小时绿色 CL，怎么办？

  • 建立一个 build cop 的三人小组，每周五和每周一关注 TAP greenness
  • 如果超过 10 个小时 TAP 还是红色，需要紧急处理，保证每周发布有可靠的基准 CL

• 回归测试中有可能 P2 的 bug 实际是 P1 的

  • 测试完成后，发现的 bug 经过 TLs(Tech Leader) 再次审核来决定 P2 的 bug 是否需要 Cherrypick
  • 回归测试结束后需要有个 sign off 的过程

• 如何知道新功能可以测试了？

  • 从 Feature bug 中拿到开发最后一个 CL，在 cl-status(一个辅助工具) 里查询
  • 辅助的 Chrome 插件工具

• 怎样方便的获取错误日志信息，有助于开发快速定位修复发现的 bug

  • 辅助的 Chrome 插件工具

• 上线后发现问题如何处理？

  • Eye3 监控机制
  • Oncall 机制
  • 回滚机制
  • Cherrypick 机制
  • 剖尸机制

达成

• 确定了上面的流程，QA 团队一周的时间分配自然也就有了
  

• 统计每周发布情况了解产品是否稳定
  

• 顺利运行后大大缩减回归时间，同时 CP(Cherrypick) 的数量减少

• 有更多的时间投入到新功能测试以及自动化测试

后记

• 后续的改进：

  • API 加速发布： 将 API 和 FE 进行剥离，API 通过高覆盖率的自动化测试，从一周一发到一周四发
  • 兼容性测试： API 和 FE 剥离后，API 会有三个版本比 FE 新，引入兼容性测试，保证 FE 稳定
  • 上线时间定在每周四： 这样有问题周五处理，不用周末加班

• 关于每周发布
  几年的每周发布做下来，发现每周发布对团队的压力很大，基本每天有明确的任务，虽然回归时间从 2 天减到 1 天，但是每周超过 3 个新功能没有任何喘息时间，不利于团队成员反思。个人体会最理想的情况还是两周一次发布。

结尾

从事测试 12 载，一直比较喜欢参与面向客户的产品，不管这几年测试行业的称谓从测试到测试开发到工具开发，还是觉得自己就是测试工程师。近几年发现，仅仅做测试执行，学习测试技术运用，远远没有推动整个团队的测试质量提升更有成就感。