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

引言

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