只有产品顺利的发布给用户使用并获得良好反馈，整个团队的价值才有所体现。
引言
不知不觉，从 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 载，一直比较喜欢参与面向客户的产品，不管这几年测试行业的称谓从测试到测试开发到工具开发，还是觉得自己就是测试工程师。近几年发现，仅仅做测试执行，学习测试技术运用，远远没有推动整个团队的测试质量提升更有成就感。
选 1
你们的自动化测试代码如何做到那么快的编写出来的？有没有什么窍门？
顶国文老湿
1
看起来好牛逼的样子
好文顶 推动测试质量确实比较有成就感
我们每两周一个版本 ，第一周先上测试服（PTR），第二周再上正式服 
一直比较喜欢参与面向客户的产品 楼主你是不是抖 M 啊
特地前来给大佬点赞
另外再加个选项 6.一周两次呗
围城
回复
客户的需求，首先有产品经理进行过滤，分类、排优先级，然后和研发团队沟通讨论实现的方案。
客户需求，不会全盘接受，你说的坑人需求是否有经过讨论？这些没有解决的话，后续工作开展就有问题了。
围城
回复
这是你公司模式问题，需求的问题你可以另外开帖写写你们的故事，本帖主要讨论发布。
如果没有需求分析，前置工作没做好，后面怎么做都会碰到返工折腾，这个网上已经有很多有趣的图。
1、无固定发布周期
近几年发现，仅仅做测试执行，学习测试技术运用，远远没有推动整个团队的测试质量提升更有成就感。
刚入行的时候看了不少测试的、软件工程之类的书。觉得在目前软件开发水平分工和垂直分工这么多的情况下，一个基础扎实的新人，在没有过多帮助的情况下，一天之内搭建一个自用的环境，并且可以信任它的表现和生产环境一致性很高，应该是基础的要求吧。现在觉得现实真是无情。
“欸，好像是个 bug 。”
不对，前置项刚被别人改了。
换一条……还不对，这条历史数据有问题，大概有人直接改数据库个改错了。
算了，从头造……还不对，这里调用方是写死的，只能固定的 id 才有效
那就用固定的……“喂，A 君，这个 id 我正在用你怎么改了。”“一会就好，稍等稍等 “
固定 id 也不对，总该是 bug 了吧……“我们组用另一个 IP ，你绑错 host 了” “但是依赖功能要用另一个呀”“那我不知道，你想想办法吧”
折腾半天，终于想办法绕过了，还不对……“哦，依赖服务的测试环境被他们改坏了，还没修，你试试用生产吧”
好，试就试……“哎呀不行，这里有加密、测试和生产密钥不一样”“那做个挡板？”“行啊、你问运维开权限吧”
“不能用 szrz 传文件呀？”“不能，用 FTP”“FTP 每次传都要输密码呀”“是的”
还不对，欸怎么数据没变， 怎么 500 错误了……哦刚有人在发布
还不对，大概是 bug 吧，提到系统里。“过来看看啊，我本地复现不了啊”……看了半天之后 “你本地配置文件多久没更新了啊，和线上差太多了啊”
“你用的参数不对呀”“是 B 君给我的参数表”“哦，测试环境没用那个，给你另一份，用这个算”
还不对，大概可能也许是 bug 个吧？
“嗯，是 bug ，这个问题我昨天发现已经改了，你重新发布下测试环境就好了”
“@#%！#@%￥￥#”
我现在也是作为测试管理和执行了公司的发版工作，现在还处于 jenkins＋shell 脚本阶段。测试生产环境分离，敏捷模式，发版周期基本在一周两周之间，对质量的控制现在没有成体系，自动化测试未来会推，公司发展很快，测试细枝末节的地方太多了，期待大神新作啊
—— 来自 TesterHome 官方 安卓客户端
这不就是一个发布 pipeline 吗
@oscarxie 请问你们的 Test Automation Platform 是开源的吗？
我们现在是处在第二个阶段 - 每周发布，但是还处于 GIT+shell 阶段呢
国文
回复
嗯，我们最近加上了 sonarqube 安卓和 iOS 静态代码扫描，用上了 gitlab CI 做持续集成，以及 oneapm 线上监控，这些都已经用上了但是没有集成总的一起，最近在搞自动化测试方面的内容，感觉在这条路上，你们走的很快，向你们学习
确实搭建平台和工具是一方面，推动团队理念的改变并接受去使用才是基础，这个事情光靠一个工具团队玩不转
这篇我表示今天才看。。
