只有产品顺利的发布给用户使用并获得良好反馈，整个团队的价值才有所体现。
引言
不知不觉，从13年接手Google Doubleclick Sales Manager到今年7月，4年经历了3个milestone, beta, GA最终和ad exchange集成，一路走来，冷暖自知。
开始前做个调查，大家的项目发布周期是如何的，可以在回复里打数字：
- 无固定发布周期
- 每周发布
- 每两周发布
- 每月发布
- 更长的发布周期
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环境
- 下图是Rapid(Release Automation Platform in DevInfra)系统中一个完整的发布过程
新功能发布
-
每个新功能都有单独的功能开关
-
每个新功能都建立一个新功能类别的bug，让所有参与人有一个统一的沟通渠道，保证信息是同步的
-
新功能上线申请表，有若干检查项
-
如果新功能上线发现重大问题，可以快速的关闭
碰到的问题与解决
-
TAP可能不能获取到最近三小时绿色CL，怎么办？
- 建立一个build cop的三人小组，每周五和每周一关注TAP greenness
- 如果超过10个小时TAP还是红色，需要紧急处理，保证每周发布有可靠的基准CL
- 建立一个build cop的三人小组，每周五和每周一关注TAP greenness
-
回归测试中有可能P2的bug实际是P1的
- 测试完成后，发现的bug经过TLs(Tech Leader)再次审核来决定P2的bug是否需要Cherrypick
- 回归测试结束后需要有个sign off的过程
-
如何知道新功能可以测试了？
- 从Feature bug中拿到开发最后一个CL，在cl-status(一个辅助工具)里查询
- 辅助的Chrome插件工具
- 从Feature bug中拿到开发最后一个CL，在cl-status(一个辅助工具)里查询
-
怎样方便的获取错误日志信息，有助于开发快速定位修复发现的bug
- 辅助的Chrome插件工具
- 辅助的Chrome插件工具
-
上线后发现问题如何处理？
- Eye3监控机制
- Oncall机制
- 回滚机制
- Cherrypick机制
- 剖尸机制
达成
-
确定了上面的流程，QA团队一周的时间分配自然也就有了
-
统计每周发布情况了解产品是否稳定
-
顺利运行后大大缩减回归时间，同时CP(Cherrypick)的数量减少
-
有更多的时间投入到新功能测试以及自动化测试
后记
-
后续的改进：
- API加速发布： 将API和FE进行剥离，API通过高覆盖率的自动化测试，从一周一发到一周四发
- 兼容性测试： API和FE剥离后，API会有三个版本比FE新，引入兼容性测试，保证FE稳定
- 上线时间定在每周四： 这样有问题周五处理，不用周末加班
-
关于每周发布
几年的每周发布做下来，发现每周发布对团队的压力很大，基本每天有明确的任务，虽然回归时间从2天减到1天，但是每周超过3个新功能没有任何喘息时间，不利于团队成员反思。个人体会最理想的情况还是两周一次发布。
结尾
从事测试12载，一直比较喜欢参与面向客户的产品，不管这几年测试行业的称谓从测试到测试开发到工具开发，还是觉得自己就是测试工程师。近几年发现，仅仅做测试执行，学习测试技术运用，远远没有推动整个团队的测试质量提升更有成就感。
