目录

这次分享大致分为三个模块，分别是为什么要这么做、解决过程中的探索和实践、以及我个人对小程序开发的思考。

为什么要这么做？

首先我解释一下为什么要这么做，左边的场景是我们之前测试的场景，首先在一个版本群里@相关人员，在群里扔一个二维码，然后发一个列表

发布阶段

方案描述

然后会发生什么？

研发部门会问：“测试通过了吗？”“等一下”

5分钟后……

研发又问：“搞定了吗？”“搞定了。”

但是很尴尬的是可能会弹出一个产品B说我某个功能还没测试完。

由于有产品A，有产品B，所以可能还会有测试A，有后端B，这就导致沟通周期比较小。

在这个小群里，每天历史记录中最常说的语句就是“测试过了吗”、“审核通过了吗”、“发布了吗”，我们戏称这就是现实版的“三次握手”协议，也是这个小群里最“暖心”的问候语。

发布时间统计概览

据统计，每次发布大概需要 20 分钟，如果每天发布三次，每天需要 1 小时才能发布完成。而且发布并不是一个接一个，而是有间隔的，中间还要计算发布过程中涉及的同学，比如后端、测试、设计、产品等工作“打断”的成本，利益相关者很难有集中的 time 来做事情。

这会导致人们对发布版本的想法产生抵触情绪。我记得我听到的最常见的一句话是，“啊，又要发布一个版本了？”这会拖慢整体的迭代进程。

但对于一家创业公司来说，快速迭代、快速试错是非常重要的能力，这种状态显然是不可接受的。

时间都去哪儿了？

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

这是一个简单的过程吗？在理想情况下，是的，但现实往往更加复杂。

那么复杂性在哪里呢？

第一点是关键信息

提交审核/测试前，一定要检查关键信息。为什么？因为你修改的是发布环境，改变的版本信息是手动修改的。不管一个人多么严谨，都有出错的可能（ps：其实我挺怂的，我干过两次这种事）

第二点就是信息同步的问题，从左图可以看到我们有两个步骤需要确认，一个是测试步骤，一个是审核步骤，这里一般会做什么呢？

用一句话来概括就是：“产品/运营等其他相关方很难第一时间获取发布信息，缺乏有效的告知方式。”其实就是信息同步的问题。

查询场景

方案描述

你以为这就结束了吗？在日常工作中，“嘿，我们在上一个版本发布了什么需求？”这是一个非常常见的问题。大多数情况下，我们都会很快给出答案。

但是很多人会问这个问题，它的上游是接客服，技术，产品，市场BD等部门的。

根据职责不同，人数不同，问询次数会乘以n倍。

以下是根据职责可能会问这个问题的部门：产品，运营，技术，客服......好像公司大部分职位都已经覆盖了。

可见，这是一个长期且重复的沟通行为。

很头疼，其实是缺少更新日志或者文档的问题

变更日志要求

左图是微信小程序的更新日志文档，大致包括：

可以一目了然地看到每次迭代发布了什么，以及何时发布，无需再次询问。

但是刚开始没有这个文档的时候该怎么办呢？一是根据tag去查看对应的git log，二是手动记录这样的wiki

这两种方法都存在一些问题：

第一个问题是除了当前项目的开发人员之外，无法获得准确的信息，比如产品/运营/客服同事。首先我们不能指望每个人都使用git。另一方面，源代码隐私也是一个问题。

第二个问题是

（当然也可以用直接生成，但是和队伍的提交风格冲突）

不幸的是，没有，所以很痛苦。

总结

解决方案

概述

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

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

总体流程图

通过自动化构建，我们发布试用版本，并上传到git，然后git利用其能力发送到我们自己的服务器，处理日志信息，上传版本快照，存储处理后的数据，通过邮件服务通知各个方向，最后展示在视图层。

自动构建

构建该流程需要哪些能力？

首先解决构建问题，在做任何事情之前，我们需要思考一个问题：构建过程需要具备哪些能力？

这个gif是我们自己搭建的脚手架工具的发布流程，可以看到这是一个交互式的导航，输入xdk-cli命令后会提示

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

具体计划

那么输入 xdk-cli 会做什么？

为了保证可扩展性，cli只保留了上传和版本管理功能，预留了两个hook函数，分别在发布前和发布后执行。一些针对项目定制的任务都放在hook中，比如lint、sass，以及小程序的npm功能，还有git以及git tag的提交。

如果你对cli的具体实现感兴趣，可以微信扫一扫下面的代码，这是我之前写的一篇关于cli搭建的文章

好处

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

从流程角度来说，我们的好处是什么？

变更日志

关于更新日志，我们的目标是帮助非项目开发人员快速了解每次迭代的更新信息。

三个问题

以上就是我总结的三个核心问题，做这件事情之前你一定要想清楚：

对于第一个问题，需要包含哪些字段呢？最基础的有：版本号，版本描述，上线时间，需求列表，其次就是需求的一些开发人员和审阅者，以及需求关联的Pr、Prd是什么，以及当前版本的状态。

怎么看？在哪里看？我们把它放到我们内部的线上管理平台上，以表格的形式展示出来。

日志记录何时更新？当版本状态发生变化时，如提交测试、评审、发布或回滚时

产出需求

上面三个问题其实概括了我们要做的事情，分别是数据采集，数据存储，状态管理，事件钩子，视图层。

这时候发现本地搭建已经不能满足这些要求了，需要一个稳定的线上服务器来处理这些任务，我们使用node来搭建

现有流程

这是我们现有的更新日志的流程，上面一整层都是节点服务。

首先通过流程将代码上传到git，git通过通知节点服务，收到通知后更新服务器本地代码，提取中间提交信息和版本信息，压缩上传到OSS做版本快照，最后将准备好的数据插入

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

案例展示

这个图是我们管理系统的截图。

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

以下是项目所包含的信息：需求类型、需求列表，需求列表中每一项又包括开发人员、评审人、评审时间、关联pr、关联prd

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

关键

整个过程的关键点就是如何把这么完整的信息整合起来，其实一条信息就是通过，，版本信息，OSS存储信息等合并起来的。

为什么要把和这两个跟Git相关的功能分开来讨论呢？

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

Git Msg 依赖 tag hook，tag hook 的定义是新版本的诞生，主要从 git log 中提取相关版本信息，但统计维度无法具体到 PR 节点，获取更详细的数据，比如 PR 标题，开发者等。

依赖于Pr hook，每次提交Pr时都会记录相关信息并存入数据库。

其实就是使用了两套不同的钩子服务，入库的时候分属两张不同的表，取数据的时候根据prId进行表关联。

左图是实际的信息，从日志信息中提取出来，推入数组中；右图可以理解为Pr表，里面是需求相关的详细信息。

如何解析msg?npm上有很多第三方的包，很方便。

沟通机制

再说最后一个沟通模块，这样做的目的是为了解决“产品/运营等其他相关方难以第一时间获取发布信息，缺乏有效的通知方式”的问题

提取关键字

这里我们可以从这句话中得出几个关键词：首次、获取发布信息、通知手段。这三个关键词也是我们未来要重点解决的方向。

第一是关键时间节点，因为这个特性，所以需要确定几个推送的关键时间节点，这里我列出了四项：测试状态、审核状态、发布状态、回滚状态。

第二是内容详情，我们肯定需要高质量的版本信息，上面提到的更新日志是一个现成的服务，我们用它作为数据源，提供必要的数据。

第二是通知方式，多种多样，有邮件，钉钉，微信等，由于我们用的是企业邮箱，开发成本比较低，所以直接用第三方库搭建邮件服务

关于状态转移

分为手动更换和自动更换两步

手动更改

现阶段手动修改是主要的修改方式，也是备用方式，大致形式如右图，提供了各种状态的按钮，每次状态改变都会通知到节点服务中的邮件模块，帮助我们发送群消息。

又一次黑客攻击

自动修改是一个比较hack的操作，本质上是因为小程序公众平台暂时没有提供hook能力，所以我用了一个叫油猴的浏览器插件在网页上添加了这样的hook。

左图可以看到，当点击提交的时候，会触发脚本绑定的自定义事件，这个事件直接调用我们服务提供者状态流的接口来帮我们进行修改，而不需要去后台进行修改。

期待微信团队后续能够开放这样的钩子能力，帮助我们实现不依赖本地客户端的功能闭环。

当前发布流程

这是最新的一套流程，首先各个小组进行自测，合并 PR，通过命令直接上传试用版本，提交审核，同时发邮件提醒已审核，审核通过后各个小组进行集成测试，最后发邮件提醒已发布。

新流程每次发布大概需要5分钟，最重要的是它是非阻塞形式，发布期间你可以做自己的事情。

实施这个新流程后，这个测试组里的“三次握手”场景就成了历史，这个组从最热变成了最冷。

价值提取

首先是解决我们前面提到的一些问题，比如：

它还可以帮助团队成员扩展他们的技术边界——接触不同的东西

一些未来计划

一些个人想法

之前有很多同学问我：“小程序开发天花板低，不利于职业发展，怎么办？”我一开始也有类似的想法，经历了一些事情，总结了以下几点：

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

什么是追求卓越？就是在完成一项任务之后，要总结、检讨如何做得更好。即使目前的资源在现阶段无法支撑你实现，也要确保自己具有可扩展性。

当我能思考清楚以上5点的时候，我觉得我不仅应该把自己定位为一个小程序开发者，更应该定位为一名互联网从业者。