本文是字节跳动发布工程团队的高磊讲师在2021 GOPS 全球运维大会中「字节跳动亿级DAU客户端发布最佳实践」的分享全文。
首先做一下自我介绍:我是字节跳动发布工程团队的工程师高磊。从事软件开发工作有10多年的时间,在传统软件公司还有一些创业公司都做过,最近大概6,7年时间基本专注在DevOps方向,也积累了一些自己的理解和经验。
今天我分享的主题是【字节跳动亿级DAU客户端发布最佳实践】,通过今天的分享,希望大家可以了解字节在客户端发布方面做的一些实践。本次我将从四个方面来进行分享,分别是:1.移动端发布的特点难点,2.字节移动发布体系的介绍,3.移动发布的实践总结,4.未来的展望。
1. 移动发布特点&难点
我们先从移动发布特点难点开始。
发布这个概念应该属于CD(持续部署)的范畴,也就是Devops的一部分。平时我们接触的比较多的是服务端Devops,今天的分享主题看似会偏客户端一些,但大部分的内容和理念应该是相通的;本来我之前想的是,如果能到场的话,我会做一个现场的调研,看下到场的做客户端的同学比例;不过既然现在没有这个机会,我先简单介绍服务端和客户端的发布流程的区别:
其实这里的内容并不复杂,但作为我们后续内容的一个背景铺垫还是有必要讲的。
从构建打包到包出来的这个阶段,两者应该区别不大,无非底层依赖的打包工具略有差异,最本质的区别在于出包后的流程;服务端的更新流程,是把打出来的二进制包发到我们自己的服务器上,所以他的整个过程是可控的,一方面你可以随意更新新版本;另一方面呢,万一上线的版本有问题,也能做到一键回滚;但客户端是不行的,我们的包打出来以后,一般我们会把新版的包放到服务器上,如果对于正式包,我们会上传到商店来托管,但用户什么时候过来更新,我们是不知道的;如果这个版本有问题,那你也没有办法很快会退到上一个版本,你还得规规矩矩的再走一遍这个发版的流程,这个止损的成本是比较高的。
这就是两者最大的区别:客户端升级依赖终端,不完全取决于平台,这个特性也决定了两者在版本发布全周期其他方面的不同。
具体来说,首先是部署介质,这个上面提到了,一个是可控的服务器环境;另外一个是复杂变化的终端设备,操作系统有Android/iOS, Android有很多不同的厂商,比如小米,华为, vivo等等;
第二,服务端的版本概念比较弱,一般来说,我们不用版本号去定位某次服务端的发布,但客户端不同,我们的交流语言就是某某版本,版本号是客户端发布里面非常重要的一个信息;
第三个差异点是发版周期,服务端的发版一般没有明确约定,有新功能的话可以每天都更新,一天发多次都是常态;这个也符合Devops持续交付的理念; 移动端,一般准备周期比较长,目前主流的节奏可能是1到2周一个大版本,也有一些不常更新的应用甚至可以一个月才发一次版;
第四个差异点是参与人群,服务端一般情况下只要测试阶段通过,到了发布阶段基本上就是RD来主导,但客户端因为版本比较珍惜,一个是一个,所以在发版阶段设计了很长的链路,每个阶段都会配不同的角色去完成某项工作,现在字节不少团队还有QABM这个角色,就是QA里面专门负责发版管理的同学;整体分工可以说越来越精细和复杂了;
第五点是止损效率,这个之前已经提到过了,不能很快的回滚止损这个“硬伤”可以说是造成客户端和服务端发版差异主要的原因;
最后一点是多版本并行,服务端显然常态下只会保留一个最新的版本,在上线或者灰度阶段会短暂的多版本并行一段时间,但是客户端历史上累积的这些版本会永久的保留下来,不再变更;
那么说了这么多,相信大家对两者差异应该有了一个更清晰的认识,大家可能都会想,“客户端发版”真麻烦,这个是对的,而且因为麻烦,一旦发出去以后,就要承担一些可能的风险。
下面我给大家看几个典型线上事故的例子,大家可以看下这张PPT,这是我们线上曾经出现过的真实事故,有因为错误下发64位机型安装包到32位机型导致升级失败的,有为安装包配置错误下载链接导致安装失败的,还有使用不恰当物料导致应用商店拒绝上架的…真是什么事故都有。不难看出,移动场景下发布面临的风险很多,有安全的问题,有数据的问题,有测试的问题,稍有遗漏就会给公司造成很大的损失,或者是财务损失,或者是用户流失,这些都是我们在设计发布系统时要解决的问题。