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

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集团 / 符博娟 / 安居客质量保障部 用户质量保障部


相关文章