I just started developing a few mini programs recently (2020 is a little late for mini programs, isn’t it? Lol… Maybe there was no business need in this respect before), I spent two days tinking with the automatic deployment scheme of wechat small program (if there is something wrong, please point out to you). So without further ado, let’s get right to today’s business.

Why do you want to automate the deployment of small programs?

  • The same project is developed by many people, and the code is frequently uploaded and the version of different people is switched back and forth, which is inefficient.
  • The uploaded applets cannot be consistent with the repository code.
  • Versioning issues are not easily resolved.
  • The local submitted code, after the official version submitted for review, needs to be repackaged and released, cut back to the experience version.

Gitlab CI automated publishing solves problems

  • The efficiency of
    • Solve the problem that multiple users need to change versions frequently when uploading files manually
    • Reduce unnecessary releases (once released online, the latest version needs to be repackaged and submitted as a play version)
  • security
    • Gitlab CI release ensures that the code for the committed version has been committed to the repository. Using wechat developer tools to upload, can not protect this point.
  • specification
    • The version of the specification release that the implementation can trace back to a specific code submission record

Background knowledge

gitlab ci

miniprogram-ci

Solution ideas

  1. Packaged applet
  2. With the help of script invocation in miniProgram-CI provided by the official miniprogram, the corresponding release script is executed in combination with Gitlab CI. A. When executing the script, you need to pass the version parameters, specify the release robot, and specify the description (here we use commit Message as the description).

Integrated development & deployment

  1. Alpha release: The code is submitted to the Test branch for automatic release (commit Message as the release description). By default, the bot set in this branch is the experience version. There is no need to change the experience version for multiple releases.
  2. Release the beta version: Merge the test code into the Preview branch and automatically package it for submission. The robot set in this branch is the beta version, which needs to be submitted for review on wechat public platform. After the review is passed, the administrator will see the beta version and release it in gray scale.
  3. Release the official version: merge the test/ Preview code into the Master branch and automatically package it for submission. The robot set in this branch is the official version, which needs to be submitted for review on wechat public platform. After the review is passed, the administrator will see the online version and release it in full.

During development, there is no need to upload the code in the wechat developer tool. In the version management of wechat public platform, only the version released by the robot can be seen, and there are no versions submitted by individuals.

The integration steps

By default, you already know and use Gitlab-CI.

Install miniprogram – ci

npm i miniprogram-ci -S
Copy the code

Prepare to upload the key.

Only the administrator of the applets has permission to generate key files. The specific location is in the applets management platform, development -> Development Settings -> applets code upload -> applets code upload key. Place the generated key file in the root directory of your project. You can also turn on the IP whitelist so that the upload script can be executed using the specified IP address (in our case, the IP address of the gitlab-Runner’s machine).

Ci.js publishing script

Create the ci.js file in the project root directory

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 and privateKeyPath need to be set to const project = new Ci. Project({appId: 'appID ', type: 'miniProgram', projectPath: './', privateKeyPath: './ci-private.key', hide. [' node_modules / * * / * ', '/ SRC / * * *]}) upload / * * * / 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 })Copy the code

See the official documentation for more publishing Settings.

. Gitlab – ci. Yml ci script

# The test, Preview, and Master branches support online deployment of stages by default: 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)Copy the code

Modify the package.json file

We specified in gitlab that the Preview/Master branch does NPM run build for packaging and the test branch does NPM run build:test for packaging, so we want to support this command in package.json

{... "scripts": { ... "build": "xxx", "build:test": "xxx", ... },... }Copy the code

conclusion

To conclude, we abandoned manual uploading for the sake of efficiency, safety and regulation.

As long as the code is submitted to the specified branch for each release, the automatic packaging of the release is implemented, avoiding frequent changes of development versions due to multiple developers (which also leads to difficult management of the code version). Integrated enterprise chat tools (enterprise wechat/Nail nail) Webhook, but also to realize the release of reminders, very good experience.

Different branches have corresponding robots to release, avoiding the need to repackage and switch back to the test environment after the release of the official version.

Experience releases with the Commit SHA help us keep track of code releases.

When this solution is integrated, the code for the release version must be in the code repository to some extent avoid risk and ensure that the history is traceable.