devops 聊聊发布

oscarxie for 百家争鸣 · 发布于 2017年08月10日 · 最后由 jiazurongyu 回复于 2017年09月18日 · 最后更新自管理员 Lihuazhang · 2758 次阅读
本帖已被设为精华帖!

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

引言

不知不觉,从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 条回复
50

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

16280

顶国文老湿

115
oscarxie · #3 · 2017年08月10日 作者
16280fudax 回复

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

16280
115oscarxie 回复

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

15498

看起来好牛逼的样子

161

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

11622

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

113

特地前来给大佬点赞👍

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

115
oscarxie · #10 · 2017年08月11日 作者
11622shayang888 回复

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

115
oscarxie · #11 · 2017年08月11日 作者
113andward 回复

一周两次太苦了,过头了

11622
115oscarxie 回复

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

115
oscarxie · #13 · 2017年08月11日 作者
11622shayang888 回复

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

11622
115oscarxie 回复

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

115
oscarxie · #15 · 2017年08月11日 作者
11622shayang888 回复

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

480

1、无固定发布周期

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

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

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

104 seveniruby 将本帖设为了精华贴 08月15日 15:20
7646

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

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

115
oscarxie · #19 · 2017年08月16日 作者
7646windanchaos 回复

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

1522fe

这不就是一个发布pipeline吗

115
oscarxie · #21 · 2017年09月07日 作者
1522fecay 回复

欢迎来分享经验

1925

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

115
oscarxie · #23 · 2017年09月08日 作者
1925davidyang 回复

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

1925
115oscarxie 回复

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

115
oscarxie · #25 · 2017年09月08日 作者
1925davidyang 回复

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

1925
115oscarxie 回复

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

1522fe

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

899

这篇我表示今天才看。。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册