字节跳动亿级DAU客户端发布实践

本文是字节跳动发布工程团队的高磊讲师在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位机型导致升级失败的，有为安装包配置错误下载链接导致安装失败的，还有使用不恰当物料导致应用商店拒绝上架的…真是什么事故都有。不难看出，移动场景下发布面临的风险很多，有安全的问题，有数据的问题，有测试的问题，稍有遗漏就会给公司造成很大的损失，或者是财务损失，或者是用户流失，这些都是我们在设计发布系统时要解决的问题。