小而美的小程序自动化工具

小程序自动化

why

为什么要做小程序自动化？

如果单纯的说为什么要做，可能就是官方的话，CI/CD，自动化巴拉巴拉一堆，我认为反向来回答可能会更生动一点，如果不做自动化会怎么样？可以看看以下这些小程序开发过程中的一些问题。

猿A正在愉快的开发A功能，突然产品同学过来要看B功能，让你给个小程序的体验码，要求很合理，接下来看我一顿操作,git stash,git checkout,yarn build, 开发者工具点击生成预览码，截图发给测试同学，大功告成！然后git checkout, git stash pop,撸起袖子接着干。此时你应该觉得没什么，平时都是这么干的，也就是几分钟的事情，耽误的起。too young to simple！接下来再看看这个，此时测试同学又过来了，想要测试一下C功能开发的怎么样了，并且给个代码包，可自行导入开发者工具进行测试，同样的合理要求，不能拒绝，那接着重复上面的操作，我还能忍耐一下。

接着往下看！

此时再来两个测试同学，需要你给D功能，F功能的码，你怎么做呢？排队waiting，接着打码，时间应该至少过了近几十分钟了，当你这些都完成了，准备再次进入happy coding 的时候，第一个测试同学过来告诉你，一些刚上线的功能为什么你这个版本没有？此时你想起来，你的分支还没有跟master同步！然后你又去同步代码，重新打包。就这样，可能一上午的时间就过去了，你的happy coding还处在你刚写的一个View标签上，连个className都没来得及写！此时，你又想起来，还有一个功能需要现在进行提审,未完待续…

如果将上面的场景再添油加醋一下，你正在解决某个棘手的bug，四个预览码应该已经让你的思路断了，前面的一些准备工作已经凉了，你可能要重新在花费时间去解决。如果在来几个这样的要求，我估计你已经到了崩溃的边缘。在上述的过程中，你80%的时间还是在等待构建，小程序上传，这样的时间浪费，非常的可耻！

上面的例子，应该是在小程序开发过程中，大家都会遇到的问题，同事的需求也是合理的，你做也是合理的，但是你的时间就这么不合理的过去了。综上来看，我们正式的归纳一下，不使用自动化可能会出现的一些问题。

1. 分支切换，代码上传，预览码生成，操作无脑但耗时
2. 当生成码的要求同时来的时候，需要等待
3. 小程序单独的机制，导致无法像web端那样做整体流程管控
4. 非开发人员获取体验码的流程依赖开发人员

how

我们该如何解决现状

引入正题，我们应该用机器来代替人工完成重复性的工作，并通过机器来规范人工的流程，减少人工出错率(大家都知道)。

以微信小程序为例，官方提供了npm包，提供了上传预览的功能，这个用以解决开发者工具的人工点击问题。
构建流程工具，我们选择jenkins。我们想进行类似web端的一些检测机制，但是这层机制做在jenkins端写起来比较繁琐，且前端对于jenkins方面的知识储备并不足，因此加入一层node来解决流程管控的问题。

此外，我们还缺少一个触发机制，什么时候触发构建？

• 我们可以基于gitlab提供的hooks进行，但是该方案需要一些依赖前提，如提交commit提交，mr等，但是正常情况下非开发人员并没有git权限，此处受限。如果分支未修改的话，我们也想进行打包，此处也受限
• 我们也可以做成工具平台，需要的时候在工具平台上进行构建，但是，工具平台的开发，要完善权限页面等操作，并且后期的维护工作也较为麻烦，此处不太适合，因为我们想做一个小而美的工具，平台化适合应用较多的时候进行，且需要投入额外的人力成本。

公司内部办公都是使用钉钉的，钉钉提供了机器人，这让我们的触发机制有一个更简单的开始。因此后续流程可以如下：

1. 通过钉钉的指令触发构建
2. 以node端为中介，完成流程化操作
3. jenkins端进行打包上传预览等耗时操作
4. 回调node端，对原有的信息进行美化
5. 钉钉接收node端的信息，反馈用户

what

如何做

钉钉机器人文档

文档内容，可自行查看(程序员都是看文档的天才)
我们可以直接@钉钉机器人，输入指令

从钉钉端接收到的请求体如下：

接收到的是字符串，我们使用类似cli的格式对参数进行解析，以便我们可以在node端进行一些配置化操作，其他的两个参数，用以做回复以及角色判断使用。

因为jenkins处有容器创建启动等操作，较为耗时，也会存在资源排队问题，此时可先通知用户，jenkins端已响应，也就是上面的容器启动中。

此时我们可根据指令参数，进行对应的操作，在jenkins端拉去对应项目的分支代码，然后走打包构建的流程，构建成功后，可将产物暂存于oss中。

构建成功后，透出选项预览以及下载，用户可点击预览功能进行多次的预览码生成操作，下载可提供源码，服务端同学或者测试同学，可自行下载产物代码，导入开发者工具进行联调或测试。构建成功后，会自动进行预览码生成操作。

每个步骤都会通知用户当前的进行状态，以避免不知道流程进行到哪一步。

此时预览成功

通过配置参数来决定是否上传至微信做体验版，或者待发布版本

node端作为中介，完成了jenkins与钉钉端的信息流转，同时也做了一些流程管控以及优化策略。

1. 构建之前，会对分支进行检测，该分支是否与master分支保持同步，如果未保持同步，则强制要求保持同步。此处限制是为了避免测试同学测试未更新的代码，从而导致返工的问题

2. 构建锁，如果多次@机器人构建统一分支，则后续的构建都不再进行，当构建完成后，释放锁，以避免一些不必要的构建

result

该工具开发约2天时间, 一周后稳定运行。
目前支撑三个小程序，支撑50+产研同事，已支撑消费者主业务发布7个月。

唯一的不足之处就是为对构建数据进行统计，所以大家懂得。。

写在最后

通过该小而美的工具，我们极大的提升了开发测试效率，也保证小程序端也有了一定的流程控制。在整个流程中，通过已有的知识储备解决了业务中的痛点。

而且整个工具的开发流程中，遇到问题，解决问题，一步步完善工具，解决业务痛点。这也就是如何在业务中提升自己的一个例子。

本文并不是一个可直接copy来完成的应用，而是在讲述一个解决问题的过程。如何进行选择，如何提升投入产出比。

文中如有不妥之处，欢迎指导~

欢迎关注公众号，菜青虫的青菜园，后续将定期更新

公众号文章