聊聊Google DSM产品的发布

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

引言

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

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

DSM如何做发布

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

常规的每周发布

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

  • 发布流程见下图

 

聊聊Google DSM产品的发布_第1张图片
 

 

  • 从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)系统中一个完整的发布过程
      聊聊Google DSM产品的发布_第2张图片
       
    • Rapid系统自动创建一个候选包
      聊聊Google DSM产品的发布_第3张图片
       
    • 同时运行webdriver自动化测试(TAP上一般执行UT和ServiceTest, UI test耗时单独跑)
      聊聊Google DSM产品的发布_第4张图片
       
    • 将候选包发布到QA环境,自动创建当周的release bug和hotlist, 上到QA环境后运行screen diff
      聊聊Google DSM产品的发布_第5张图片
       
    • QA测试完成Sign off后陆续发布到Canary和Prod环境

新功能发布

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

     

     

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

    聊聊Google DSM产品的发布_第6张图片
     

     

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

    聊聊Google DSM产品的发布_第7张图片
     

    聊聊Google DSM产品的发布_第8张图片
     

    聊聊Google DSM产品的发布_第9张图片
     

    聊聊Google DSM产品的发布_第10张图片
     

     

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

碰到的问题与解决

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

    • 建立一个build cop的三人小组,每周五和每周一关注TAP greenness
      聊聊Google DSM产品的发布_第11张图片
       
    • 如果超过10个小时TAP还是红色,需要紧急处理,保证每周发布有可靠的基准CL
       
  • 回归测试中有可能P2的bug实际是P1的

    • 测试完成后,发现的bug经过TLs(Tech Leader)再次审核来决定P2的bug是否需要Cherrypick
    • 回归测试结束后需要有个sign off的过程
  • 如何知道新功能可以测试了?

    • 从Feature bug中拿到开发最后一个CL,在cl-status(一个辅助工具)里查询
      聊聊Google DSM产品的发布_第12张图片
       
    • 辅助的Chrome插件工具
      聊聊Google DSM产品的发布_第13张图片
       
  • 怎样方便的获取错误日志信息,有助于开发快速定位修复发现的bug

    • 辅助的Chrome插件工具
      聊聊Google DSM产品的发布_第14张图片
       
  • 上线后发现问题如何处理?

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

达成

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

    聊聊Google DSM产品的发布_第15张图片
     

     

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

    聊聊Google DSM产品的发布_第16张图片
     

     

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

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

后记

  • 后续的改进:

    • API加速发布: 将API和FE进行剥离,API通过高覆盖率的自动化测试,从一周一发到一周四发
    • 兼容性测试: API和FE剥离后,API会有三个版本比FE新,引入兼容性测试,保证FE稳定
    • 上线时间定在每周四: 这样有问题周五处理,不用周末加班
  • 关于每周发布
    几年的每周发布做下来,发现每周发布对团队的压力很大,基本每天有明确的任务,虽然回归时间从2天减到1天,但是每周超过3个新功能没有任何喘息时间,不利于团队成员反思。个人体会最理想的情况还是两周一次发布。

结尾

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

你可能感兴趣的:(聊聊Google DSM产品的发布)