用户
 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,登录网站

小程序社区 首页 教程 查看内容

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

Rolan 2021-6-21 00:55

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

小程序自动化

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分支保持同步,如果未保持同步,则强制要求保持同步。此处限制是为了避免测试同学测试未更新的代码,从而导致返工的问题

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

result

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

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

写在最后

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

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

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

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

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

鲜花
鲜花
鸡蛋
鸡蛋
分享至 : QQ空间
收藏
原作者: web菜青虫 来自: juejin