前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >达到什么标准就可以上线了?

达到什么标准就可以上线了?

原创
作者头像
静儿
发布2019-03-31 17:43:58
4740
发布2019-03-31 17:43:58
举报
文章被收录于专栏:编程一生编程一生

背景

《程序媛的人生观》这篇文章中,一些朋友提出了自己的疑问:“看起来静儿的发版上线很不规范,为什么一个大公司会允许这样的事情呢?”这是个很好的问题,值得我好好总结分享一下。

在考虑上线标准之前,先考虑这么一个问题,你处于哪个通道?

通道

前端通道、系统通道和后台通道的发版上线流程差别会很大。

前端通道:用户体验、视觉效果会占很大比重,一般来说需要依赖专业人员进行人工测试。

系统通道:产品流程的理解和把控是其中的一个关键点。自动化测试基础上还需要人工测试进一步验证。

后台通道:也是静儿所在的通道。业界有一个比较流行的理念:“开发人员应该测试自己的代码。”

我们团队中经常在说的一句话叫:“你不可能既当运动员又当裁判。”那怎么来解决这个冲突呢?

自动化测试。基础架构这边有专门的QA。他们大部分时间都在收集测试用例,开发自动化测试工具。

开发人员需要自己写单体测试,单体测试是在设计阶段,对功能进行建模阶段就写好的。所以对一个后台开发来说,完全可以在几分钟之内完成一套完整的上线前验收。

能否在几分钟之内就可以进行一套完整的上线前验收也和公司、部门或者团队的策略有关系。

策略

不知道有的朋友有没有注意到这个问题:有的公司虽然是大公司,但是门槛并不高。面试的时候着重考察面试者的理解力、沟通能力。如果背景不错,不会太卡技术这一块。当然,一般来讲这种公司给的待遇也比较一般。

这并不是说这个公司不够好,相反,正是因为公司有非常完善的流程把控,所以才摆脱了对成员个人能力的重度依赖。然而,一般来讲,流程是用来保证底线的。一个注重成员成长的团队希望的是能够激发成员的上限。

所以静儿所在的团队有这么一种策略:如果成员对自己的流程把握足够好,不出问题,上级会逐渐放宽对成员的监督。如果把控的不好,就会天天被盯流程。

这样的好处:做的好的成员的创造性可以充分得到发挥。对于上级自身,也可以抽身出来cover更大的事情。

《程序媛的人生观》这篇文章中,静儿用了一个很不专业的词:「临时决定」。从另一个角度来看这个问题,什么事情是可以临时决定的?

定性

静儿之所以可以临时决定给序列化和反序列化接口新添加一个实现。这里面包含了两点信息:

1.这是添加实现,最最坏的情况下,实现出问题了,是可以开关切换切换回原来的实现的。

2.这不改变完成的功能,就是说这是一个重构。

在开发的时候「忍不住觉得之前的代码写的太烂了需要重构」是一个工程师的基本素养。如果回过头看觉得原来的代码写的不错,这是一个信号:同学,你该看书学习了。

所以,对于新功能,静儿团队中是需要开会一起做DEMO验收演示的。但是对于重构,开发人员完全有权利自己决定何时重构。因为功能不变,之前已有的自动化测试流程无需任何更改,完全可以覆盖重构后的场景。

背后的技术支撑

「技术强就是任性。」这句话不错的,但是技术强不是指静儿个人的技术能力。而是我司的整套基础设施。这里就不谈我们强大的DevOps这些东西。我们就说《程序媛的人生观》这篇文章中,静儿提到终于用了整个晚上,到凌晨5点完成上线,静儿最后把线上到哪里了呢?

上到了线下环境。这里线下环境是什么概念呢。静儿所在的团队负责的是容器的生命周期管理。容器有给广大用户直接访问的线上环境。还有一个环境,业务部门是我们的用户,他们用来测试、开发的容器,对我们来说是正式环境。如果线下环境出了问题,会影响我们的用户满意度。

一般来说,我们的代码想上到线上环境,至少要经常两天的线下环境观察。这个观察是什么意思呢?

发版前写好发版checklist,在一定范围内周知说我要发版了,如果有问题请及时联系我。

然后采用灰度发布,每发版一组机器就要进行整个流程的检验,如果有问题最快的解决方法是将有问题的机器禁用。每组发版之间有强制的时间间隔,在间隔内不能发版下一组。

发布完成后QA那边的自动化工具又一次起了作用,它会自动模拟用户完成所有分支的操作。然后给出报告。

各方面都OK之后,周知说发版完成符合预期。第二天一大早起来业务巡查,看看是否一切正常。

一天的午高峰和晚高峰监控数据是一定要看的。CAT、OCTO、业务大盘、监控大盘……

最重要的是及时看看是否有业务反馈问题。这都是在线下环境做的。

《程序媛的人生观》这篇文章中提到的那次发版,由于质量好。上周四发版线下,上到线上环境是这周一晚上9点后开始操作。

从「技术好就是任性」这个再延伸一下,为什么《程序媛的人生观》这篇文章中看起来编码很随意?这是因为设计架构做的好。临时决定给序列化和反序列化接口新添加一个实现。实现加在哪里了呢?每个产品至少有两个服务组成:核心服务和非核心服务。我们的MQ都是用来数据预处理用的,都是在非核心链路上。出问题了,半夜临时挂一下,就算有和静儿一样的程序员在半夜扩容测试机器。服务产生的最坏影响是数据反应有延迟😀

总结

昂贵的工具不一定能制作出更好的设计。--《程序员修炼之道》

相关阅读

《程序常用的设计技巧》

《引入服务网格》

《到底多大才算高并发?》

《美团分布式服务通信框架及服务治理系统OCTO》

《学会用数据说话-分布式锁究竟可以多少并发?》

《大话高可用》

《业务开发转基础开发,这三种「高可用」架构你会么?》

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档