安居客小程序持续交付之路

2021-03-15 00:00:00 程序 发布 流程 上传 送审


导读

随着小程序的日益发展，对于小程序付过程中的各种问题也越来越值得我们关注，本文介绍了安居客小程序持续交付从无到有的整个过程，以及过程中各阶段遇到的问题、思考及解决方案。


背景

安居客小程序业务覆盖新房、二手房、租房、 商业地产四大核心领域，负责这四块业务的也是不同的团队；与此同时，目前活跃的小程序达到了4个，并且分布在微信、百度、支付宝3个平台上。

由于业务发展较为迅速，每个小程序每周有2次常规发版，此外还有不定期的各种小版本发布工作。而每次发版过程并非一帆风顺，早期的时候，由于涉及的团队多、流程长且无明确规范，导致整个过程较为艰辛。随着流程的逐步完善，作为平台方QA的我们，义不容辞地接手了发版工作，但同时也带来了巨大的挑战。
下图展示了一次发版工作基本的工作内容，其中还省略了各种通知、确认环节。可以看到，平台方在其中承担了较多的重复工作。


痛点分析

作为平台方，我们不仅需要进行日常业务的测试工作，还需要负责各个小程序的发版工作。而在此过程中存在以下痛点：
  1. 发版平台多：目前负责发版的小程序包括了安居客微信小程序、58房产微信小程序、安居客百度小程序、安居客支付宝小程序，其中涉及到了微信、百度、支付宝三个小程序平台，而对应的发版过程中，上传操作需要打开各自平台不同的开发者工具，后续送审、发布环节则需要在各小程序管理后台进行手工操作。
  2. 发版频率高：早期没有固定的发版日期，单个小程序每周可能会发布5-10次，对于发版同学来说，这可能意味着需要更频繁的在正常工作及发版任务中进行切换，对于负责发版的同学，这种体验非常糟糕。
  3. 发版成本高、效率低：由于部分小程序在上传前需要先对代码进行编译，从而导致每个参与到发版的QA同学都需要安装对应的开发环境及工具、修改相关配置以及拉取代码，导致了发版成本较高；而编译过程有时又比较耗费时间，需要不时的关注，影响正常工作效率。
针对以上的痛点，我们在整个持续交付演进过程中，通过必要的流程规范及技术手段，进行了优化及解决。

持续交付进化之路

流程规范
小程序的发布初由开发人员执行且没有固定发布窗口，这导致了上线随意、线上问题不容易定位到具体引起的版本等问题。于是我们在接手发版工作后固定了小程序发布的时间为每周一周三，由统一的上线人员负责编译打包、生成体验码给对应的上线项目人员验收，各业务线验收通过后送审及发布。对于紧急需求，需要申请上线。
至此整个上线流程已较为规范，但对于上线人员的操作问题也逐渐显露出来了，比如针对不同的小程序，需要安装不同的开发者工具、配置编译环境等，而编译过程中经常会报各种环境问题、同时开多个开发者工具会有卡顿等问题。

本地阶段
为了解决同时打开多个开发者工具时卡顿、开发者工具偶尔报错的问题，通过调研了解到各个小程序有提供对应的CI-SDK或者命令行方式将代码上传到小程序后台，于是，我们开始通过本地调用各个小程序SDK的方式执行上传，具体方案如下：
  1. 安装各个小程序的SDK，微信（miniprogram-ci）、百度（swan-toolkit）、支付宝（alipay-dev）；
  2. 配置各个小程序后台：
    微信：微信公众号获取上传密钥文件（调用SDK上传需要传入的参数）、关闭ip白名单；
    百度：在百度智能小程序开发者工具获取登录密钥；
    支付宝：小程序后台配置工具id和工具密钥、关闭ip白名单。
  3. 本地编写调用SDK执行上传的脚本，可根据具体小程序SDK必传参数传入对应的参数值即可实现上传代码至小程序后台。
以上步骤均可在各小程序官方文档中找到具体方案，在此不做过多展开。
通过脚本方式实现代码上传至各个小程序后台，这种方式虽然可以解决开发者工具上传遇到的问题，但同时本地直接调用SDK实现上传也会出现一些使用不便利的问题，如脚本是通过node的方式执行的，需要安装node环境，还需安装对应小程序的SDK，且上传只是小程序版本发布的其中一个部分。还是需要手动拉取代码、编译、获取体验码、送审、发布等。

Jenkins
为了解决本地使用SDK上传但整个流程并不完善的问题，也为了使整个上线流程更加规范化，我们把小程序上线流程引入到Jenkins中。流程如下：

通过Jenkins我们把之前本地的部分操作统一到了Jenkins的一个Job中，并将体验版二维码在构建历史中进行展示：

虽然通过Jenkins实现了小程序上线过程中的拉取代码、上传代码及获取体验码的功能，也解决了编译环境等问题，也可以直接拿到体验版本的二维码。但是在使用一段时间后发现，在整个Jenkins操作过程中也会存在一些问题：对于送审和发布的操作，需要等待体验版验收通过和小程序方审核通过才能继续，所以无法建立单独的Job来执行，而创建多个Job的话维护成本又较高等问题。

平台化
为了解决在Jenkins中遇到的问题，于是我们有了将整个流程平台化的想法。同时也调研了一下业内的解决方案，发现大多是针对微信平台的，且整个流程涉及的环节与前文中Jenkins基本一致，而对于多个小程序平台及后续送审、发布等环节没有比较完善的方案。
调研的同时也发现小程序App和常规的移动App在整体交付过程中有一定的相似之处，都包含了编译、打包等环节，而集团的移动端持续交付平台在Android和iOS App这块已经做得相对成熟，于是本着不重复造轮子的思路，我们决定在iCI已有功能的基础上进行小程序能力的扩展。
经过技术方案分析后发现，流程中代码拉取、编译、打包、送测等环节可以在比较大程度上进行复用，而需要补充的功能为一系列小程序特有的流程环节，包括上传、设为体验版、送审、发布。
由于上述小程序节点功能本身比较独立，所以我们在整体设计上，我们决定将这块功能作为单独的服务来实现（此服务后续称为MpService），减少与iCI的耦合也方便后期的扩展。系统间的交互使用接口调用及回调的方式来进行。针对上传、设为体验版、送审、发布这几环节分别暴露相关的接口以提供服务。

确定好大方向后，我们还有一个问题尚需解决：
  • 针对设为体验版、送审、发布这三个功能，官方并未提供对应的SDK，在此之前只能通过手工操作页面的方式进行。
针对这个问题，由于没有对应的SDK或是接口可以使用，所以我们决定基于UI自动化的方式进行实现，对于UI自动化，我们首先想到的肯定是Selenium，但是Selenium中我们常用的Driver，如FirefoxDriver、ChromeDriver等，都需要启动一个真实的浏览器并进行GUI层面的渲染以及执行JS代码，因此存在执行效率低以及环境安装成本高等问题。虽然也有类似HtmlUnitDriver等无头浏览器的实现，但在对JS的支持上不够好，会导致元素定位不到等问题。在经过调研之后，我们发现Puppeteer[2]在当前场景下较好的解决了Selenium的各种弊端，所以终选择使用Puppeteer来驱动UI自动化。
[2]Puppeteer：Puppeteer is a Node library which provides a high-level API to control Chrome or Chromium over the DevTools Protocol. Puppeteer runs headless by default, but can be configured to run full (non-headless) Chrome or Chromium.
参考来源：https://github.com/puppeteer/puppeteer

整体架构如上图所示，整个服务分为两大块：
  1. 基于小程序SDK的上传服务，对各个小程序上传SDK进行了封装，并提供上传各个小程序到对应管理后台的服务。这部分需要根据SDK的要求在对应的小程序后台设置好对应的配置项，具体操作与上文本地阶段所介绍的相同，执行过程只需要根据接口传入的参数去调用对应的上传SDK即可。
  2. 基于UI操作的服务，主要提供获取体验码、送审、发布服务。根据传入的参数，决定具体是执行哪个平台的小程序中的哪个操作，并通过Puppeteer驱动页面操作。
这其中会有一个难点，各平台的管理后台是需要通过扫描二维码的方式进行登录的，而浏览器本质上是运行在MpService上的，并且MpService又是无头浏览器。因此我们需要解决的问题是如何把二维码在前端页面，也就是iCI中进行展示。
针对此问题，我们的解决方案是通过Puppeteer对二维码区域进行截图并上传，生成对应的图片URL，将此URL地址以回调的方式告知iCI，从而在前端页面进行展示。同样的，针对体验版二维码的展示，我们同样也可以使用此方法。具体展示效果如下：

以上传及设为体验版为例，执行流程如下图所示：

主要功能接口实现方案：

针对权限安全方面，iCI的权限管理做了层保障，而小程序后台的各项操作，前提需要登录，而登录的二维码也需要对应权限才能通过。因此在安全方面也无隐患。
至此，我们将小程序流程中的各个环节操作统一到了一个平台上，后续所有操作不用再分散在各处，也不用安装配置各种环境。此外整体系统在设计上较为通用，因此不同小程序在接入过程中的成本也相对较小，目前集团中已有十余个小程序接入。

效果及收益

小程序持续交付平台化的实现，为团队工作提效与质量保障都带来较大收益及效果，主要体现在以下方面：
  1. 发版成本降低：在小程序平台化后，负责发布的同学不再需要安装各种环境及开发者工具，也无需打开任何开发者工具就可进行编译、打包、上传的工作；同时，在提审、发布等环节也不需要去到各小程序的后台进行手工操作。
    目前仅在安居客相关的4个小程序上累计各迭代了26个版本，粗略估算，每个小程序单次流程可节约30分钟。
  2. 流程透明化：作为平台方，早期在发版日当天下午，各业务方会频繁询问新集成包的相关信息以及发版流程节奏。而目前来说，我们可以依靠平台能力，大家可以实时的拿到新的集成包，以及查看发布流程的整体进度。
  3. 构建包统一管理：与Android及iOS对于历史版本包的需求类似，基于目前的平台，我们已实现了对小程序的各个版本历史包的统一管理。
  4. 业务快速接入&多平台快速扩展：目前除了安居客小程序，集团已有十余个小程序接入；基于目前的平台架构，后期如果再有其他平台的小程序，如头条、手Q等需要接入，可以实现快速接入。

总结

本文主要叙述了在面对小程序的测试及发布环节中的各种问题时，如何通过节点抽象，流程统一，操作平台化等方法，对整体流程逐步完善的过程。在提升了团队效率的同时，也建立起了一套针对各端小程序通用的持续交付方案。
由于篇幅限制，一些实现细节并未在文中一一阐述，如果大家发现文章中的错误或者实现方案上有更好的选择，欢迎在评论区留言交流指正。

作者简介：
58集团 / 秦偲晟 / 安居客质量保障部 工程效能部
58集团 / 符博娟 / 安居客质量保障部 用户质量保障部


相关文章