阅读 1032

重新定义微信小程序发布流程

原文地址:www.yuque.com/jinxuanzhen…

目录

这次的分享大概分成三个模块, 分别是为什么做这件事,解决过程中的探索与实践,和我个人对于小程序开发的一些思考

为什么要做这件事?

image.png

首先说下为什么做这件事情,左图这个场景是我们之前的测试场景,首先在一个版本群里,@一下相关人员,丢一张二维码在群里,然后再发一个check list

发布阶段

场景描述

然后会发生些什么呢?
研发会问: 测试通过了么?
”稍等“
隔个5分钟后
研发再问:”好了么“
“好了”,
但是很尴尬的有可能跳出一个产品b说我这边还有个功能没测完,既然有产品A,产品B,那么也有可能有测试A,后端B,这就陷入了一个沟通小循环

image.png

每天在这个小群里,历史记录里频次最高的发言就是就是"测好了么",“过审了么”,“发版了么”,
被我们戏称为现实版的“三次握手”协议,也是这个小群里最“暖心”的问候

发布时间统计概况

image.png

大概统计了下,每次发版的时长在20分钟左右,按照每天3次发布来计算,每天要花1小时的时间用来进行发布,而且发版并不是一版接一版,它是有间隔的,中间还要计算参与发版流程的同学,例如后端,测试,设计,产品等角色工作被“打断”的成本,作为相关方很难有集中的块状时间去做事情

这样会导致大家对发版这件事情有抵触情绪,
我记得当时听到最多的一句话就是,“啊,又发版了?”
这样整体迭代是速度快不起来的,

然而作为创业公司来说,快速迭代,快速试错是一个非常重要的能力,这种状态下明显是一件不太能接受的事情

时间花在了哪?

image.png

可以看左图,这是最开始小打卡最开始的一个发布流程,即
修改发布环境 -> 点击上传 -> 填写版本号/版本描述 -> 发布体验码测试 -> 提交审核 -> 点击发布

这是一个流程简洁么?
在理想状态下是的,然而现实情况往往要更复杂一些

那么复杂在哪里?

第一点就是check关键信息
提审/提测前是一定要去check关键信息的,为什么?
因为是修改发布环境,更改的版本信息是人工来进行修改的,不论多么严谨的人都是有出错的可能性(ps: 其实挺不好意思的,我就干过这个事,而且两次)

第二点是信息同步的问题
从左图可知,我们是有两个需要经过确认环节的,一个是测试环节,一个是审核环节,这里通常会发生什么事呢?

这里可以一句话概括为“产品/运营等其他相关方很难在第一时间获得发布信息,缺乏有效的通知手段”,其实就是信息同步的问题

查询场景

场景描述

image.png

以为这就结束了么,在日常工作中,“hey咱们上个版本发了哪些需求”这是一个再寻常不过的问题了,大部分情况下我们会很快给出答案

然而会问这个问题人可就多了,它的上游对接的是客服,技术,产品,市场bd等等部门

根据不同的职责属性,和人数,这个询问次数会被乘以个n次
下面是,根据职责划分,可能会询问这个问题的部门,产品,运营,技术,客服...
貌似已经覆盖了大部分的公司职位了

可见是一个长期且重复性相当强的沟通行为

很头痛,但是实际上就是缺了一份更新日志或者说是文档的问题

更新日志需求

image.png

左图是微信小程序的更新日志文档,大概包含了:

  • 版本号
  • 更新日期
  • 需求列表

可以看到每个迭代发布了什么,什么时候发布的一目了然,自然不需要再来进行询问这个动作

但是我们刚起步没有这份文档的时候怎么办呢?
一是根据tag标签去查对应的git log,二是手动去记这么一份wiki

两种做法都存在一定问题:

第一种的问题是除当前项目的开发人员,无法准确获取信息,例如产品/运营/客服同学,首先并不能指望每个人都可以使用git,另一个方面源码私密性也是一个问题

第二种的问题在于

  • 完整性的问题,人为记录更多会选择性的记录,例如里程碑式的业务需求
  • 信任度问题,当存在不完整的可能性时,就变成了参考而非答案
  • 需要付出额外的人力成本

(当然还有可以利用commit message直接生成,但是和团队的提交风格相冲)

image.png

很可惜,没有,所以,很痛

总结

  • 减少无效沟通,避免重复性时间损耗,提高团队效能  --从团队效率上来说,我们并不希望“三次握手”事件的发生
  • 保障信息同步能力,确保组织内部信息的一致性和即时性   -- 作为公司的主要产品迭代信息是一定要透明化的,不同部门之间合作才不会出现偏差
  • 提高版本稳定性,杜绝潜在的发布风险 -- 这个下一话会讲
  • 最后一个是满足一天多次的发布需求 -- 如果按照现在的发布效率来看,1天1-2次就是极限了,不能解决沟通成本问题反而是降效

解决方案

概况

image.png

就小打卡目前的解决方案来说,将问题大概分为了3个模块

  • 自动化构建    - 主要负责打包编译,具备发布体验版的能力
  • 更新日志       - 提供版本记录,版本快照能力
  • 通讯机制       - 主要负责提供有效的通知手段

这里面有一个简单的依赖关系,
更新日志依赖构建能力提供原始数据集,通讯机制主要功能是同步消息,但是内容依赖更新日志

总体流程图

image.png

通过自动化构建,发布体验版并上传到git,git再通过webhook能力打到我们自己的服务器,处理log信息,上传版本快照,将处理后的数据存储到mysql,通过邮件服务,通知到各个方向,最后是视图层进行展现

自动化构建

构建流程需要具备哪些能力?

image.png

首先解决构建问题,首先做事情之前我们要先想一个问题,构建流程需要具备哪些能力?

  • 打包编译的能力 - 解决语法转换/条件编译/代码检查等一系列问题,同时可以在这里定义一些全局常量,例如之前遇到的切换环境的问题
  • 发布能力 - 提交体验版的通用做法是点击小程序开发工具的右上角“上传按钮”,其实除了这个方式之外微信提供了另外两种提交方式,命令行和http服务,具体情况可以翻下微信文档
  • 版本管理的能力 - 主要是帮助我们规划相关的版本号和版本描述,可以类比npm的version manager
  • 最后是要保证一定的扩展性,例如小程序目前支持npm构建功能,如果没有流出扩展空间,是需要去改源代码添加的,并且这套构建流程在一定程度上是需要保障多项目适配的

1564577781256-eb6c59cd-5fee-43ea-a72c-06510148c8e9 (1).gif

这个gif是基于我们自己的一个脚手架工具实现的一个发布流程,可以看到这是一个交互式的导航,
输入 xdk-cli publish 这个命令后会询问我们

  • 是否发布正式环境
  • 设置一个版本号(这里填写版本号有一个增长逻辑,默认阶段版本号 + 1)
  • 填写一个版本描述

其实就是一个 切换环境 + 填写版本信息的过程,之后便是进入发布环境

具体方案

image.png

那么输入 xdk-cli publish 到底做了些什么事呢?

  • 读取项目的本地配置文件,包括脚手架配置和版本管理文件,
  • 然后弹出询问命令,填写需要确认的相关信息
  • 执行发布钩子
  • 上传体验版,执行微信提供的上传命令
  • 执行发布后钩子
  • 上传体验版成功,返回一个回调

这里为了保障扩展性,cli只保留了上传和版本管理的功能,
预留了两个钩子函数,分别是发布前后执行,针对于项目定制化的一些task都放在了钩子内,例如babel,lint,sass,小程序的npm功能,也包括git commit, git tag 的提交

好奇cli具体实现的可以微信扫下面这个码,是我之前写的一篇关于搭建cli的文章

带来的收益

左图是优化后的流程,可以看到通过 cli , 我们合并了“修改发布环境 + 点击上传 + 填写版本信息三个环境“,通过直接通过交互命令进行发布,

单从流程角度讲,我们的收益是什么

  • 杜绝了切换线上线下环境问题导致的发布错误
  • 版本号填写错误的问题成为历史
  • 合并了发布环节,整个提交流程只需要在编辑器中进行即可

更新日志

关于更新日志,之前背景中有介绍我们的目标是:**帮助非项目组开发人员快速了解每个迭代的更新信息 **

三个问题

image.png

上面是我归纳的三个核心问题,在做这件事之前时一定要想清楚的:

  • 哪些字段需要收录
  • 怎么看?在哪里看?
  • 什么时候更新日志记录

关于第一个问题,哪些字段需要收录?
最基本的有:版本号,版本描述,上线时间,需求列表
其次是一些需求的开发人员,审核人员,并且该需求关联的Pr 和 Prd是什么,以及当前版本的状态

怎么看?在哪里看?
我们是放在自己内部的线上管理平台上,利用表格的形式展示

什么时候更新日志记录?
版本状态出现变动的时候,例如提测,提审,发布,回滚的时候

产出的需求

image.png

上面的三个问题其实也总结出我们要准备要做些什么。分别是 数据采集,数据存储,状态管理,事件钩子,视图层

  • 数据采集很好理解,收集一些字段
  • 数据采集完需要存储到一个线上可访问的数据库,方便我们视图层和后续的一些应用
  • 事件钩子,什么时候通知我们需要更新数据,变更状态
  • 视图层,承载内容的地方

这时候发现本地构建已经很难满足这些需求了,
需要一台稳定的线上服务器的来处理这些任务,我们这里是用node来搭建

现有流程

image.png

这个是我们关于更新日志的现有流程,上面这一层整个是node服务

先是通过构建流程上传代码到git, git通过webhook能力,通知到node服务,收到通知后更新服务器本地代码,提取中间的提交信息和版本信息,压缩上传oss是为了做版本快照,最后将准备好的数据插入mysql

视图层可以根据存储好的数据展示相应内容

案例展示

image.png

这个图是截的我们管理系统的一张图,

从左到右分别是:版本号,描述,状态,发布时间
还有两个功能选项: 修改状态,下载代码包(其实就是做过处理后的快照)

下面是项目包含的信息:需求类型,需求列表
需求列表的单个item里又有开发人员,审核人员,审核时间,关联pr,和关联的prd

可以看到整个版本信息结构是一目了然的

关键点

image.png

整个流程最关键的点是怎么整合这样一份完整信息,
实际上一份信息是通过 git Msg,Pr Msg, 版本信息,和oss存储信息 合并而成的

为什么git Msg和Pr Msg同属git相关的能力要分开说? 

image.png

主要是因为生命周期不同,

git Msg依赖于tag hook,tag hook的定义是新的版本诞生,主要是从git log中提取相关版本信息,但是统计维度没办法具象到PR节点,得到更详细的数据,例如Pr标题,开发人员等等

pr Msg依赖于Pr hook,每次提交Pr都会记录相关信息并入库
实际上走的是两套不同的hook服务,入库时也分属不同的两张表,取数时根据prId进行表关联,

看下左图是实际的version信息,这里根据log信息提取出pr_id,推入数组,
右图可以理解为Pr表,里面有需求相关的详细信息

具体怎么解析commit msg?npm上很多第三方的包,非常方便

通讯机制

再说最后一个通讯模块,做这个东西的意义是为了解决 "产品/运营等其他相关方很难在第一时间获得发布信息,缺乏有效的通知手段" 这一问题

提取关键词

image.png

这里可以从这句话里可以提出几个关键词,第一时间,获得发布信息,通知手段,这三个关键词也是我们后续要解决的重点方向

image.png

首先是关键时间节点,因为具备这个特性所以需要确定几个关键的时间节点进行推送,我这里列的是 测试状态,提审状态,发布状态,回滚状态 这四项

其次是内容详情,肯定是需要有质量的版本信息,关于版本信息刚才讲到的更新日志是一个现成的服务,我们这里直接将它作为数据源,提供必要数据

其次是通知方式,这个就多种多样了,邮件,钉钉,微信等等,我们这里因为用的是企业邮箱而且开发成本比较低,直接用 nodemailer 第三方库搭了个邮件服务

image.png

关于状态流转

分为两步,手动变更 和 自动变更

手动变更

image.png

目前阶段来说,手变更是主要变更方式,同样也是兜底方式,大概形式可以看右图,提供了各种状态的按钮,每种状态变更都会通知到node服务中的邮件模块,帮助我们进行消息群发

另一种hack方式

image.png

自动变更算是一个比较hack的操作,本质上是因为缺少小程序公众平台暂时没有提供hook能力,所以自己这边利用google浏览器的一个叫做油猴的插件在网页上加了这样一个钩子

可以看左图点击提交的时候,会触发脚本绑定的自定义事件,这个事件直接调用我们服务商状态流转的接口帮助我们进行修改,不需要再去后台进行变更

非常期待微信团队后续开放这样一个hook能力,帮助我们不依赖本地客户端实现功能闭环

当前的发布流程

image.png

这是最新的一套流程,首先是各个组内自测,合并pr,通过命令直接上传体验版,并提交审核,同时发送邮件提醒已经审核,各小组收到审核后进行集成测试,最后邮件提醒当前已发布

新的流程每次发版消耗时间控制在5分钟左右,最主要的是他是一个非阻塞的形式,在发布期间完全可以做自己的事情

  • 对开发人员来说需要关注的环节只有,合并pr,本地执行一次命令,最后在微信公众平台操作提审和发布时的扫码工作
  • 对其他人来说,在接到邮件时,直接执行对应需要完成的任务即可

image.png

这套新的流程执行之后,这个测试小群里“三次握手”的场景成为了历史,从最暖的小群,变成了最冷的小群

价值提现

image.png

首先是解决了我们先前提到一些问题,例如:

  • 拒绝任何形式的“三次握手“,沟通成本降低,无论产品/研发更聚焦于业务本身 - 减少无效沟通
  • 具有稳定可靠可追溯的版本记录,确保组织内部信息的一致性
  • 邮件服务的送达机制,不再需要人力去传递相关信息,且及时性,完整性得到保障
  • 节省下来的资源,足以支撑一天发布多次版本的需求

也可以帮助团队小伙伴扩展技术边界  - 接触一些不一样的东西

关注下面的标签,发现更多相似文章
评论