原文地址及ppt： https://www.yuque.com/jinxuanzheng/gvhmm5/uy4qu9

目录

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

为什么要做这件事？

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

发布阶段

场景描述

然后会发生些什么呢？

研发会问： 测试通过了么？”稍等“

隔个5分钟后…

研发再问：”好了么““好了”,

但是很尴尬的有可能跳出一个产品b说我这边还有个功能没测完，

既然有产品A，产品B，那么也有可能有测试A，后端B，这就陷入了一个沟通小循环

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

发布时间统计概况

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

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

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

时间花在了哪？

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

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

那么复杂在哪里？

第一点就是check关键信息

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

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

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

查询场景

场景描述

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

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

根据不同的职责属性，和人数，这个询问次数会被乘以个n次

下面是，根据职责划分，可能会询问这个问题的部门，产品，运营，技术，客服…貌似已经覆盖了大部分的公司职位了

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

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

更新日志需求

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

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

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

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

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

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

第二种的问题在于

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

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

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

总结

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

解决方案

概况

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

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

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

总体流程图

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

自动化构建

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

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

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

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

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

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

具体方案

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

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

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

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

带来的收益

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

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

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

更新日志

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

三个问题

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

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

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

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

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

产出的需求

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

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

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

现有流程

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

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

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

案例展示

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

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

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

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

关键点

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

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

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

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上很多第三方的包，非常方便

通讯机制

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

提取关键词

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

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

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

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

关于状态流转

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

手动变更

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

另一种hack方式

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

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

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

当前的发布流程

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

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

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

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

价值提现

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

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

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

未来的一些规划

一些个人的思考

之前有不少同学问我：“小程序开发天花板低，对职业成长不利怎么办？”，最早我也有过类似的想法，经历过一些事情后，总结出了下面的一些点：

• 在任何一个领域做到“精通”都并不容易，提出这个问题之前首先需要看到“天花板”
• 我们并不是在做小程序，而是在“解决问题”，千万不要要自我设限，认为做小程序开发只能做小程序
• 善于探索边界，主动推动并解决问题形成闭环，解决边界问题才是最有价值的事情
• 工作更重要的是学习做事方法，积累方法论，形成自己的思维框架

最后一点追求卓越非常重要，我认识的很多非常厉害并且优秀的人都有这么一项特质

什么是追求卓越？就是做完一件事情，都是要总结复盘思考怎么才能做得更好，哪怕当前的资源并不能支持你在现在的阶段去实现，但是一定要确保自己是有延展性的

当能够把上面5点想清楚的时候我觉得对自己的定位应该不仅仅是小程序开发者了，而是一个互联网从业者