基于gitlab ci的小程序自动化部署方案

Roy_Pu
4,502 阅读5分钟

最近才开始着手开发了几款小程序（2020年才开始搞小程序，是不是有点晚了，哈哈...可能之前也没有这方面的业务需要吧），就花了两天时间捣鼓了一下微信小程序的自动化部署方案（如有不正之处，请各位大佬指出）。那么废话不多说，直接进入今天的正题吧。

为什么要做小程序自动化部署方案？

  • 同个项目多人开发，频繁上传代码，来回切换不同人的版本，效率低下。
  • 上传的小程序代码和代码仓库的代码无法保持一致。
  • 版本控制问题无法很好解决。
  • 本地提交的代码，发正式版提交审核后，需要重新打包发布，切回体验版。

gitlab ci自动化发布解决的问题

  • 效率
    • 解决多人手动上传需要频繁切换版本的问题
    • 减少不必要的发布（发布线上后，需要将最新的版本重新打包提交设置为体验版本）
  • 安全
    • gitlab ci发布，确保提交版本的代码已经提交到仓库。使用微信开发者工具上传，则无法保障这一点。
  • 规范
    • 规范发布的版本，实现可追溯到具体的代码提交记录

背景知识

gitlab ci

miniprogram-ci

方案思路

  1. 打包小程序
  2. 借助小程序官方提供的 miniprogram-ci 中的脚本调用方式，结合gitlab ci执行对应的发布脚本。 a. 执行脚本时需要传版本参数、指定发布机器人、描述说明（这里我们将commit message作为描述）

集成后的开发&部署方式

  1. 发布alpha版本：代码提交到test分支自动发布(commit message作为发布的描述说明)，默认此分支设置的机器人就是体验版本，多次发布无需切换体验版。
  2. 发布beta版本：将test代码合并到preview分支，自动打包提交，此分支设置的机器人就是beta版本，需要在微信公众平台提交审核，审核通过后，管理员看到是beta版本，进行灰度发布。
  3. 发布正式版本：将test/preview 代码合并到master分支，自动打包提交，此分支设置的机器人就是正式版本，需要在微信公众平台提交审核，审核通过后，管理员看到是线上版本，进行全量发布。

开发时，无需在微信开发者工具中上传代码。 微信公众平台中的版本管理中只能看到机器人发布的版本，不再有个人提交的版本。

集成步骤

默认你已经了解并使用过gitlab-ci。

安装miniprogram-ci

npm i miniprogram-ci -S

准备上传密钥

密钥文件只有小程序的管理员有权限生成。 具体位置是在小程序管理平台中的，开发->开发设置->小程序代码上传->小程序代码上传密钥。 将生成的密钥文件放在项目的根目录下。 这里还可以开启ip白名单，指定的ip才能执行上传脚本（我们这种方案里，就是gitlab-runner所在的机器的ip）。

ci.js 发布脚本

在项目根目录下创建ci.js文件

const ci = require('miniprogram-ci')

// gitlab-runner执行脚本时，传进来的参数，
// 第一个参数为版本号
// 第二个参数是指定的机器人
// 版本的描述说明
var arguments = process.argv.splice(2)
var version = arguments[0]
var robot = parseInt(arguments[1])
var desc = arguments.splice(2).join(' ')

// appid 和privateKeyPath需要设置下
const project = new ci.Project({
  appid: '小程序的appid',
  type: 'miniProgram',
  projectPath: './',
  privateKeyPath: './ci-private.key',
  ignores: ['node_modules/**/*', 'src/**/*']
})

/** 上传 */
async function upload({ version = '0.0.0', desc = 'test', robot = 1 }) {
  await ci.upload({
    project,
    version,
    desc,
    setting: {
      es7: true,
      minify: true,
      autoPrefixWXSS: true
    },
    robot,
    onProgressUpdate: console.log
  })
}

upload({ version, desc, robot })

更多发布设置可参考官方文档。

.gitlab-ci.yml CI脚本

# test、preview和master分支默认支持线上部署

stages:
  - build

# 每次开发新版本需要修改一下版本号
variables:
  PROJECT_VERSION: 1.1.2

# 安装依赖&&构建打包
build test:
  stage: build
  only:
    - test
  tags:
    - assets-deploy
  script:
    - cnpm i
    - npm run build:test
    - node ci.js $PROJECT_VERSION.$CI_COMMIT_SHORT_SHA.alpha 1 $(git log -1 --pretty=%B)

build preview:
  stage: build
  only:
    - preview
  tags:
    - assets-deploy
  script:
    - cnpm i
    - npm run build
    - node ci.js $PROJECT_VERSION.$CI_COMMIT_SHORT_SHA.beta 2 $(git log -1 --pretty=%B)

build prd:
  stage: build
  only:
    - master
  tags:
    - assets-deploy
  script:
    - cnpm i
    - npm run build
    - node ci.js $PROJECT_VERSION 3 $(git log -1 --pretty=%B)

改造package.json文件

我们在gitlab中指定，preview/master 分支执行npm run build进行打包，test分支执行npm run build:test进行打包，因此我们要在package.json中支持此命令

{
  ...
  "scripts": {
    ...
    "build": "xxx",
    "build:test": "xxx",
    ...
  },
  ...
}

总结

最后我们来个小小的总结吧，我们放弃使用手动上传的方式来发布主要是为了在效率，安全和规范三个层面有一个提升。

每次发布只要提交代码到指定的分支，实现自动打包发布，避免因多人开发频繁切换开发版本（这还导致代码版本不好管理）。集成企业聊天工具（企业微信/钉钉）的webhook，还能实现发布提醒，体验甚好。

不同分支有对应的机器人来发布，避免了发布正式版本后，需要重新打包切换回测试环境的动作。

体验版发布带上commit sha帮助我们更好追踪代码的版本。

这个方案集成后，发布版本的代码必定在代码仓库中，在一定程度上避免风险，确保历史记录有迹可循。

avatar
文章
阅读
粉丝