The author | week sauce

This article was written in December 2019 and may be partially out of date. First in zhouzhoujiang personal blog, reproduced please indicate the source.

The release process of wechat small program is different from that of conventional Web projects. It relies more on wechat developer tools and developers. During our iteration, some problems were exposed and some processes can be improved. So we want to use the tools we have right now to reduce rework, address the release process and differences between development and production environments, and improve r&d efficiency.

The problem background

In the absence of continuous integration solutions, we often encounter several scenarios:

  1. Testing links frequently need to release small programs, small program projects are numerous, the release of tedious operation and repetitive work content, resulting in the interruption of research and development ideas, time waste.
  2. The test students cannot build and upload the test version of the small program, we need to rely on the developer to provide the test TWO-DIMENSIONAL code.
  3. A demo applet uploaded locally by a developer may carry code in local development or not pull branches in a timely way.

Therefore, what we need to achieve is that the r&d only needs to submit the code to Git, and the rest of the work is done by the machine, so that the r&d students can concentrate on moving bricks.

Knowledge reserves

Continuous integration

Continuous integration is a software development practice in which team development members integrate their work frequently, usually at least once a day per member, which means that multiple integrations may occur per day. Each integration is verified by an automated build (including compilation, release, and automated testing) to catch integration errors early. There are many continuous integration tools, the most commonly used are Jenkins and Gitlab CI, and the solutions are very mature.

Wechat developer tool ability

The reason why micro channel applets can achieve continuous integration is that micro channel developer tools open HTTP and command line to call the developer tools. The following interfaces are provided: 1. Start tool 2. Log in 3. 6. Close the developer tool. Note that the wechat developer tool only provides Windows and macOS versions. HTTP call command line call

Docker basic commands

  • Create and start the container

–name= “new name” : specify a name for the container. -D: run the container in the background and return the container ID. Run the container in interactive mode, usually together with -t. -T: reassigns a pseudo-input terminal to the container, usually together with -i. -V: binds the mount directory

  • Into the container

docker exec -it containerID /bin/bash

The environment to support

2. A Linux server We have a Linux server where the Test environment Node application is deployed, so we plan to put the packaged environment on this machine.

start

Basic process: Jenkins pulls the latest code -> builds the code -> copies the packaged code of dist directory in the workspace to the Linux server -> executes the wechat developer tool release script on the Linux server, uploads the small program to the wechat background -> Nails the robot to push the release result.

1. Install developer tools

If you use Windows or MAC as a baler, directly download wechat official developer tools to install. Since the official Linux version of wechat developer tools is not provided, so if Linux server is used as a baler, some changes need to be made to the developer tools. We need to understand some underlying principles of wechat developer tools, which can be used as additional research objects. Here we have the docker image of the wechat development tool available for use on Linux. WeChat WebDevTool in Docker(With LXDE)

Download the image and start the container: docker run -d –name wxdevtool -p 8080:80 -p 6666:9000 -v /var/opt/wxproject:/projects seancheung/wxdevtool:latest Two ports are opened in the container. Port 80 is the VNC port provided by the image. You can use this port to operate developer tools on a GRAPHICAL interface. Port 9000 is the proxy port of the HTTP service port number of the wechat developer tool. HTTP service each start port number is not fixed, but will be recorded in the user directory, in the container will get the port number each time, and use nginx proxy to port 9000, using -p mapping to our host, can be accessed in the host environment. We will then place the code for the applet in the /var/opt/wxproject directory, so by mounting this directory to the/’ projects directory of the container, we will be able to access the applet code inside the container and perform the appropriate upload preview operation.

2. Command invocation

After the container is started, developer tools can be invoked either from the command line or HTTP.

  • Command line call:
docker exec -t wxdevtool wxdevtool exec --login
Copy the code

  • The HTTP call:
The curl http://127.0.0.1:6666/loginCopy the code

Two ways can complete the basic operation of wechat developer tools, according to the actual use of the scenario to choose. With subsequent practice, the HTTP call is more suitable for my scenario, mainly because 1. It is easier to get the result of the call using HTTP. We need to obtain the returned result after executing the upload command. If the upload fails, we need to synchronize the failure reason to the nail group. If the login status fails, we will obtain the latest login QR code and send it to the group. HTTP is much better. 2. If the command line operation fails, the shell process will be automatically exited and subsequent operations cannot be carried out, which is detrimental to the flow control and condition judgment of our CI operation. However, HTTP request will not block or exit the subsequent flow regardless of success or failure. Of course, this may be my way of using the problem, there should be other solutions, after all, I am not very good at shell operation.

3. Jenkins job configuration

We have been able to successfully use HTTP requests for developer tool login, applets upload, etc. Now we need to integrate them into continuous integration tools. Before we start the configuration, we need to do the following: 1. Code git branch configurable 2. The packaged version is optional (beta and official), when we build and upload, the main difference between the official and beta versions is the build command and appId, and there is no difference, so we use the same job. 3. The version number and remarks of the small program can be configured. 4. Nailing robot access

  • Create a free-style project

  • Set source code management, and the branch name is passed in using build parameters

  • Build environment Configuration

Before you need remote access to the packaged server, add a remote server SSH credential of type SSH Username with private. The private key and username variables are then bound, revealing the parameters for the script to use.

  • Jenkins script

Now let’s go to the key part of the script. Jenkins’ configuration will be very simple, mainly implementing dependency installation, code building, and copying code to the remote server. Calls to developer tools are kept in separate script files for reuse. Here is the Jenkins shell script, read in the comments.

# set +x
#Remote server address
REMOTE_HOST=XXX

#Project folder name
PROJECT="assistance"

#Custom method to copy files to a remote directory
remote_scp()
{
  scp -rvi "$REMOTE_KEY" -o StrictHostKeyChecking=no "$1" "$REMOTE_USER"@"$REMOTE_HOST":"$2"
}

#Custom method Remotely executes server operation commands
remote_exec()
{
  ssh -i "$REMOTE_KEY" -o StrictHostKeyChecking=no "$REMOTE_USER"@"$REMOTE_HOST" "$@"
}

#Install dependencies
echo "--installing dependencies--"
npm i --no-progress

#Build projects based on environmental parameters
echo "--building sources--"
case "$BUILD_TYPE" in
prod)
  npm run build:dist
  ;;
*)
  npm run build:test
  ;;
esac

#Clean up the remote project directory and copy the built code to the remote server package directory
echo "--updating remote source--"
remote_exec rm -rf /var/opt/wxproject/$PROJECT
remote_scp ./dist /var/opt/wxproject/$PROJECT

#Execute upload applets script (the script is placed on the remote server, XCX command is the custom command of the corresponding script file, about custom shellUse the uploading command to check for information) echo "--uploading package--" sleep 2 remote_exec XCX $PROJECT $UPLOAD_VERSION $UPLOAD_DESCCopy the code
  • Developer tools package scripts

The implementation is also simple, the package script is placed on the machine where the developer tools are installed, so you can use HTTP to call the developer tools upload interface. Use the Upload interface with the following parameters

Call port 6666 under 127.0.0.1 on the host (remember we mapped the developer tools HTTP service 9000 port in the container to port 6666 on the host at startup). Several parameters have been passed in the call, corresponding to Jenkins’ parameters PROJECT, PROJECT, PROJECT, UPLOAD_VERSION, $UPLOAD_DESC respectively. Since we want to push the code bundle information after a successful publication, we use the InfoOutput parameter to store the publication information for later use.

$REQUEST_URL =http://127.0.0.1:6666 result=$(curl -h "Connection:keep-alive" $REQUEST_URL/upload\? projectpath\=/projects/$1\& version\=$2\&desc\=$3\&infooutput\=/projects/$1/uploadInfo.json)Copy the code

The result of this request can be obtained in result, and different processing will be done for different results. The login status of developer tools will expire after a period of time, so if the release fails at this time, we need to obtain the login QR code again and push it to the Dingding working group, so that we can log in in time. Because Dingpin push pictures, need to use the network address, so the two-dimensional code file will be uploaded to the static resource server.

RELOGIN = "need to log in" WEBHOOK = "https://oapi.dingtalk.com/robot/send?access_token=XXX"#Log in to the TWO-DIMENSIONAL code CDN address
QRCODEURL="https://XXXX"
#Picture uploading interfaceUPLOAD="" send_ding() { curl $WEBHOOK -H 'Content-Type: application/json' -d ' { "msgtype": "markdown", "markdown": {"title":" applet publishing failed ", "text": "Applet publishing failed \n\n > Developer tools need to log in \n\n >! [screenshot]('$QRCODEURL')\n" } }' } if [ -n "$(echo ${result} | grep $RELOGIN )" ]; then curl ${REQUEST_URL}/login\? format\=image\&qroutput\=/projects/login.png curl -F "folderName=wxdevtool" -F "file=@/var/opt/wxproject/login.png" $UPLOAD send_ding exit 1 fiCopy the code

We have got the uploaded information and stored it in uploadInfo.json file. We just need to use cat command to get the content of the file and extract the information we want. The jQ package is recommended for handling JSON.

  • The code is automatically built after submission

Build triggers using GitLab Webhooks in conjunction with Jenkins.

  • Robot push results

summary

So far, the basic functions of continuous integration of wechat small programs have been completed. Theoretically, it is not complicated, and a lot of repetitive work of front-end engineering should be handed over to automation tools. If there is any inappropriate description of this article, please feel free to comment on it.