devops 聊聊发布

国文 for 百家争鸣 · 2017年08月10日 · 最后由 陈子昂 回复于 2017年09月18日 · 3693 次阅读
本帖已被设为精华帖!

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

引言

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

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 28 条回复 时间 点赞

选 1
你们的自动化测试代码如何做到那么快的编写出来的?有没有什么窍门?

顶国文老湿

槽神 回复

求首席点评和分享你的经验啊

国文 回复

等我跟你们一样牛逼的时候再评论,经验这两年都忘完了,荒废中~

看起来好牛逼的样子

好文顶 推动测试质量确实比较有成就感
我们每两周一个版本 ,第一周先上测试服(PTR),第二周再上正式服 😅 😅

一直比较喜欢参与面向客户的产品 楼主你是不是抖 M 啊

特地前来给大佬点赞👍

另外再加个选项 6.一周两次呗😥

国文 #22 · 2017年08月11日 Author
围城 回复

什么叫做抖 m 啊,又落伍了

国文 #11 · 2017年08月11日 Author
andward_xu 回复

一周两次太苦了,过头了

国文 回复

面向客户啊,那些客户各种坑人的需求,搞的开发测试头疼的要死,你却还喜欢,你说你是不是斯德哥尔摩症😂

国文 #19 · 2017年08月11日 Author
围城 回复

客户的需求,首先有产品经理进行过滤,分类、排优先级,然后和研发团队沟通讨论实现的方案。
客户需求,不会全盘接受,你说的坑人需求是否有经过讨论?这些没有解决的话,后续工作开展就有问题了。

国文 回复

我觉得客户提的都是坑,而且我作为一个测试 我说反对根本没用 都是他们领导就定了

国文 #15 · 2017年08月11日 Author
围城 回复

这是你公司模式问题,需求的问题你可以另外开帖写写你们的故事,本帖主要讨论发布。
如果没有需求分析,前置工作没做好,后面怎么做都会碰到返工折腾,这个网上已经有很多有趣的图。

1、无固定发布周期

近几年发现,仅仅做测试执行,学习测试技术运用,远远没有推动整个团队的测试质量提升更有成就感。

刚入行的时候看了不少测试的、软件工程之类的书。觉得在目前软件开发水平分工和垂直分工这么多的情况下,一个基础扎实的新人,在没有过多帮助的情况下,一天之内搭建一个自用的环境,并且可以信任它的表现和生产环境一致性很高,应该是基础的要求吧。现在觉得现实真是无情。

“欸,好像是个 bug 。”
不对,前置项刚被别人改了。
换一条……还不对,这条历史数据有问题,大概有人直接改数据库个改错了。
算了,从头造……还不对,这里调用方是写死的,只能固定的 id 才有效
那就用固定的……“喂,A 君,这个 id 我正在用你怎么改了。”“一会就好,稍等稍等 “
固定 id 也不对,总该是 bug 了吧……“我们组用另一个 IP ,你绑错 host 了” “但是依赖功能要用另一个呀”“那我不知道,你想想办法吧”
折腾半天,终于想办法绕过了,还不对……“哦,依赖服务的测试环境被他们改坏了,还没修,你试试用生产吧”
好,试就试……“哎呀不行,这里有加密、测试和生产密钥不一样”“那做个挡板?”“行啊、你问运维开权限吧”
“不能用 szrz 传文件呀?”“不能,用 FTP”“FTP 每次传都要输密码呀”“是的”
还不对,欸怎么数据没变, 怎么 500 错误了……哦刚有人在发布
还不对,大概是 bug 吧,提到系统里。“过来看看啊,我本地复现不了啊”……看了半天之后 “你本地配置文件多久没更新了啊,和线上差太多了啊”
“你用的参数不对呀”“是 B 君给我的参数表”“哦,测试环境没用那个,给你另一份,用这个算”
还不对,大概可能也许是 bug 个吧?
“嗯,是 bug ,这个问题我昨天发现已经改了,你重新发布下测试环境就好了”
“@#%!#@%¥¥#”

思寒_seveniruby 将本帖设为了精华贴 08月15日 15:20

我现在也是作为测试管理和执行了公司的发版工作,现在还处于 jenkins+shell 脚本阶段。测试生产环境分离,敏捷模式,发版周期基本在一周两周之间,对质量的控制现在没有成体系,自动化测试未来会推,公司发展很快,测试细枝末节的地方太多了,期待大神新作啊

—— 来自 TesterHome 官方 安卓客户端

国文 #19 · 2017年08月16日 Author
润安 回复

有规律的发布是一个改进的过程,我也是通过 4 年慢慢推动的,前提是要 PM 和 TL 的支持。

这不就是一个发布 pipeline 吗

国文 #21 · 2017年09月07日 Author
蒋刚毅 回复

欢迎来分享经验

@oscarxie 请问你们的 Test Automation Platform 是开源的吗?
我们现在是处在第二个阶段 - 每周发布,但是还处于 GIT+shell 阶段呢

daivd 回复

没开源,TAP 只是 CI,我们有一整套从设计到发布的工具集,目前都还没有开源。

国文 回复

明白啦,感谢,我们最近可能会加自动化测试到 CI 中,就是感觉自己在推进测试效率提升方面很不足😂

国文 #25 · 2017年09月08日 Author
daivd 回复

这个过程还是蛮复杂和漫长的,除了工具配合,还有很多工程和沟通上的改进。
你可以从代码审核和持续集成入手,效率提升有一个量到质的过程。

国文 回复

嗯,我们最近加上了 sonarqube 安卓和 iOS 静态代码扫描,用上了 gitlab CI 做持续集成,以及 oneapm 线上监控,这些都已经用上了但是没有集成总的一起,最近在搞自动化测试方面的内容,感觉在这条路上,你们走的很快,向你们学习

确实搭建平台和工具是一方面,推动团队理念的改变并接受去使用才是基础,这个事情光靠一个工具团队玩不转

这篇我表示今天才看。。

simple 专栏文章:[精华帖] 社区历年精华帖分类归总 中提及了此贴 12月13日 20:49
simple [精彩盘点] TesterHome 社区 2018 年 度精华帖 中提及了此贴 01月07日 12:08
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册