Part 1: 小程序开发的日常

在我们的开发场景中,我们应该都遇到过这样的场景:

开发者正在思考coding时，为某个功能一步一步深入去解析,抽象,分层…… 突然有人@你,并告诉你需要为他提供一个小程序的测试环境的二维码….

好的,二维码.-____________________________-

接下来是一波非常标准化的操作:

1. git stash
2. git checkout branch
3. yarn install
4. yarn build
5. 点击“预览”，生成二维码，或点击上传，更新体验版
6. 截图,生成二维码,发给对方

生成二维码后,我们再切换自己刚才被阻塞的线程,这个过程又是"一把梭"的标准化操作:

1. git checkout branch
2. git stash pop
3. yarn install
4. yarn dev
5. ....

咦? 刚才的思路到哪儿来着? -___________________________-

深度回忆了十分钟,当你总算找回刚才思路的断点时, 另一个人又 at 你,希望再提供一个小程序的测试环境的二维码… -_________________________-

Part 2: Native 打包构建的启示

当多人协作开发同一个小程序的不同功能模块时,上述的场景会随着项目复杂度和参与人数的增加日益明显. 我们思考的是:

• 二维码的生成,是否真的需要依赖于开发者和开发环境?
• 这个过程是否可以和开发环境无关,是否测试人员在进行测试时,也无需依赖开发者提供的二维码或者测试环境呢?
• 当 QA验收或者 PM 验收时,只要保证我们的代码的交付的是完整的,后续流程,可以由 PM或 QA 自己完成,对于RD,PM ,QA 都可以减少一些多余的沟通成本.(一般规律看来,RD和地球人之间的交流总会多少有些障碍)
• 还有一类场景: 后端同学在做技术改造或者FE 的前置开发已经完成的情况下,测试环节,是否也可以脱离前端,自己搞定?

小程序的打包发布流程,从一定程度上是和 Native 比较类似的,有打包的概念,有提交审核和发布的概念

关于打包时间:
依据我们自己的情况来看,小程序的打包(预览版,体验版)时间,大概 3mins~5mins 左右.如果强依赖开发者,这部分时间是串行的,阻塞式的.

与 App 类比来看:
小程序预览, 对应APP 的打测试包的过程
上传微信后台, 对应 App Store 的审核过程
在微信后台,点击发布(灰度或全量),对应于APP发版的过程

我们的开发流程,一般是:

1. 开发
2. 联调
3. 测试(自测,QA 测试)
4. 提审
5. 上线

在联调与测试环节是需要频繁给后端以及QA,以及 PM提供 二维码. 整个开发周期,有2/5 的环节,我们需要不断重复的去打包,点击预览,生成二维码.(所以一般FE同学需要兼职一个职业:小程序二维码生成工程师)

类比 App 开发,我们发现,同样有打包的过程,人家Native并没有不停地在本地为 QA 和 PM 打测试包, (Native 同学打包时间更长.大概20-30mins),人家有专门的 CI 工具,在集群上专门打包.

我们进一步可以发现,Native 的 CI是怎么做的呢, 简化一下,可以理解为在 N 台云主机上都跑编译打包工具或服务,不停的对发起打包请求的响应,并打包.再细节一点,可以发现,shell 做的事情也非常的标准化:

1. git checkout branch
2. git pull
3. pod install
4. xcodebuild xxx
4. 打包xxx,上传到服务器xxx

和我们上边的人肉操作过程是不是有点相似…😓

所以,打包构建过程线上化: 本质就是开发过程与构建打包分离. 构建和打包的重复操作让机器完成, 让开发者更加关注于开发本身. 以自动化的方式, 提高效率的同时,关注度分离. 开发过程与打包构建过程的分离,进而可以使开发和测试并行化,减少沟通成本和整体效率.

Part 3:小程序持续交付 Core(原理&功能)

参考Native 的 打包和构建流程并结合小程序的登录验证等特点的特殊性,小程序持续交付Core的基本架构如下:

持续交付Core 部分的基础功能包括:

• Preview & Release: 借助微信开发者工具 HTTP 方式实现小程序的预览与上传到微信后台
• 请求队列: 多请求同时到达是,放入缓冲队列.
• 异常重试机制: 因各种异常情况,构建(预览, 后台提审)过程失败, 会重试3次,以保证成功率.若依然失败,则返回失败信息.
• Log日志: 存储并记录登录,预览,发布等事务,监控预览,发布成功率.

小程序持续集成 Core 对外是一个 API Server :提供三种对外接口

1. 登录
2. 预览
3. 微信后台提审

Part 4: Talos +小程序持续交付 Core 架构

Talos 前端持续交付平台

Talos 是基于前后端分离思想设计的一套前端 DevOps 解决方案，是为满足前端的工程从创建、开发、构建、持续集成、持续交付、统一部署、运维、数据运营等一系列需求的平台，平台基于开闭原则设计，满足多业务多部门的多样化需求，满足前端持续集成的需求，有效的保障产品的体验和质量。

结合我厂优秀的前端持续交付平台之后,故事继续展开:

整体架构图

交互时序图

Part 5: 小程序持续交付

有了持续集成以及更进一步的持续交付，意味着我们可以将更多人工操作的流程自动化，规范化、并且寻求效率的提升,我们可以做到:

• 最核心的 ,关注度分离. 打包过程 与开发过程分离. 需要打包的同学可以按需在Talos 上一键打出自己所需的特定环境的包(st, 线上)
• 多套开发和预览环境, Talos 提供自定义模板的能力,可以根据各自的业务特点,配置不同的环境.
• 一键接入. 不完全统计,全公司大大小小的小程序,可以自主在 Talos 上接入. 每次预览和打包(5mins-10mins) 计算,长期来看可以节省一笔不小的时间开销
• 消息推送.当打包成功后,会有消息推送.触达方便.
• 规范化发布流程.发版控制, 版本周期的锁定可以基于工具来实现, 集成集团统一静默期控制，以及各个业务线自定义的静默期时间，静默期内的发版，需 TL审批.
• 多层审批&干系人周知 & double check.release 操作,周知相关的 PM,QA. 发布 release 版,例如: QA或 PM 可以进行回归验收后 approve.
• 发布日志,以我们自己的开发经验来说,在此之前缺乏长期的发版日志维护列表,一段较长时间内的功能上线节点(盘点和回溯)的难度很大.
• loading…功能太多,地方太小写不下 😃

Part 6: 关于使用

当我们在 Talos 平台上点击 preview 或者 release 按钮后, 后面的过程依然是一把梭的标准化操作.

以默认流水线流程为例:

整体流程大致如下：git clone -> 安装依赖 -> 构建 -> 打包上传到对象存储，保存发布历史 -> 生成预览码链接 -> QA 发布前预览验证功能 -> 推送微信后台 -> 周知相关同学（相关群）

1. git pull 
2. git checkout branch
3. yarn install
4. yarn build
5. upload  打包上传到对象存储，保存发布历史
6. 调用 小程序 CD Core API, 等待返回二维码
7. 将二维码 通过消息推送给相关同学

嗯,这一波操作是不是很最开始我们人肉操作的那一波很像…🤣

当你点下开始按钮后面的过程我们不需要关心, 关注度分离,另一方面, FE同学甚至不需要关注是谁正在打包,以及谁打了包.

至此, 你的世界大概会比之前清静一点点,你可以静下心来思考,提炼,抽象…思考下如何让世界变得更美好一点.

Part 7: 关于展望 & 探索

整体来看,小程序的发展日新月异, 而基础建设方面, 小程序相比于Native 和 H5 的基础建设 ,处于洪荒时代(个人感觉), 从开发,DevOps,自动化测试,到多平台…很多空白需要填补.

一项新技术从产生到发展,我们在一步步摸索,有很多值得思考和探索的方向:

• 性能监控 & 性能优化
• 小程序UI自动化测试
• 多平台转换方案：mpvue 一套代码多平台适配，以及微信到其他平台之间的代码转换适配（其他小程序，RN，H5等）
• 小程序持续集成进一步深入化&效率提升
• loading…

都值得大家一起思考与探讨.