[图片]

开发背景 测试同学反馈小程序测试工作流过于繁琐，是否可以简化流程？ 步骤如下： 开发同学在功能提测阶段，需提供功能分支名给到测试同学，比如说：[代码]feature/monthcard[代码] 测试同学需要切换功能分支，并且拉取最新代码，执行 [代码]git checkout feature/montcard[代码] [代码]git pull origin feature/monthcard[代码] 打开 [代码]小程序开发者工具[代码]，更改配置文件环境参数，如：[代码]config.js[代码]，比如说修改成 [代码]env = test/dev/pre/pro[代码] 等等，切换到对应的接口环境进行测试 如只需要本地测试，直接在工具上面测试即可，如需要移动端测试，则需要点击 [代码]编译执行[代码] 生成小程序预览码，手机扫码测试 后期开发同学推了代码，需要同步测试同学定期去更新代码，执行： [代码]git pull origin 分支名[代码] 弊端 开发与测试共用一个功能分支，如果测试不小心将本地代码 [代码]push[代码] 到远端，代码出错，功能异常； 测试同学需要修改项目代码的配置文件，经常导致本地代码工作区不干净，由于 [代码]git shell[代码] 水平各有差异，接连出现拉取代码失败，或者切换分支不成功等若干问题； 需要每位测试都下载 [代码]小程序开发者工具[代码]，实属多此一举； 技术调研 基于上述的一些问题，我发现这一系列的测试步骤通过一些微信官方提供的命令行工具，是可以完全抽象出来，做成一个可以简化测试工作流的工具平台，听着是不是很棒？ 下面就是我的一些调研发现： miniprogram-ci 是从微信开发者工具中抽离的关于小程序/小游戏项目代码的编译模块。 开发者可不打开小程序开发者工具，独立使用 miniprogram-ci 进行小程序代码的上传、预览等操作。 微信ci文档地址 美滋滋，完美~~~ 技术选型 由上述 技术调研，我发现既然微信官方为我们提供对外的小程序构建预览码，上传预览的接口抽象成了一个第三方的应用包，那接下来就是选用哪些技术栈去搭建这么一个工具平台了，我的初步方案如下： 前端（js） React 搭建前端骨架（借用facebook提供 [代码]create-react-app[代码] 脚手架即可） Bootstrap 作为前端界面布局的ui框架库 后端（nodejs） 采用 [代码]Express[代码] web应用开发框架搭建即可 安装 [代码]miniprogram-ci[代码] 包（构建预览码，提交发版等） 安装 [代码]html2json[代码], [代码]objects-to-csv[代码] 包（用于项目静态资源使用分析等） 备注：在文末我会把开源的项目地址贴出来，里面的一些技术细节实在难以在这一篇文章描述清楚。 效果展示 [图片] 项目图片静态资源使用分析 我在做这个工具的时候，也把原先关于 小程序项目优化 的几个功能点也给整合进来了，做了一些有意思的玩意，顺便也给大家分享一下： 小程序的一些让人诟病的点 小程序没有诸如 [代码]webpack[代码] 的 [代码]tree-shaking[代码] 的功能，无法对项目没有使用的资源剔除出去，也就是说，同一个小程序项目的所有代码，图片等资源文件会一股脑的打包进去，体积过大； 项目文件数量过大，导致构建扫描时间过长，多余页面，或者组件等代码无法得知； 效果展示 于是乎，历经日月沧桑，针对我们项目体积过大的问题，我能想到的就是先把没用的图片找出来，删除掉，先解决燃眉之急，不然连生发预览码都无法生成了（主包大小超过2048k则报超出最大体积，无法生成预览码的错误）。 备注：如要了解解决思路的可以留言我，或者直接去看代码，基本一看就懂。 [图片] 项目地址 个人主页： https://github.com/csonchen 项目地址：https://github.com/csonchen/mpcode-manage 码字不易，关注点赞留言一把嗦~~