background
I just ran off to a new company. The front end of the new company is responsible for the development of small programs for more than 40 customers, and is the main account for them.
In other words, a set of code that switches between multiple Appids to package and upload multiple applets to publish.
So every release, colleagues cut to cut, a troublesome batch, tired on the run.
So there needs to be a set of automated deployments that frees development from this and lets operations/implementations do the release and development just focus on code development.
Technology selection
There are two types of technology selection.
Small program support mode selection
As you can see on the miniprogram website, they support three approaches
The command line V2
http
Ci ️ ❤ ️ ❤ ️ ❤ ️
The reasons are as follows:
First, we need to make it clear that the so-called command line V2 and HTTP remote calls are actually dependencies
Wechat developer tools
The introduction of this app is very clear, so I’m not going to take screenshots.
Under normal circumstances, such a strong dependency on application is definitely not preferred when there are other dependencies.
So we chose miniprogram-CI. Please refer to the official website for detailed introduction.
Miniprogram-ci has four command line invocation commands:
Preview; Upload; NPM packaging; Set up the proxy.
See the official website for details.
Two. Realization mode selection
Jenkins build ️ ❤ ️ ️ ❤ ️ ️ ❤ ️ ❤ ️ ❤ ️
Provide a GUI page to invoke the Node service ❤️❤️❤️❤️
Homemade CLI integration ️❤️️❤️❤️
The reasons are as follows:
Jenkins’ old build tool: dedicated to various workflows. Mature scheme is preferred.
Provide GUI page to invoke Node service: since our business has a special customer management platform, we can consider providing some pages or functions on it to facilitate the operation personnel to release. However, the current service interface is written in Java, and there may be some technical risks associated with using THE NPM package of CI. But from a business perspective, it works best.
Homemade CLI mode integration: in the starless front-end journey (three) — CLI project debugging can see that we are doing some CLI tools, so we can put these things into the CLI tools, global installation can be used. But our intent is to leave these tasks to the non-technical people running/implementing them, so we rule that out.
To sum up, the technical selection is Jenkins construction +CI
The next step is implementation
The implementation is actually quite simple.
1. Go to wechat to add the whitelist of uploading codes and download the private key of uploading codes
Official website address after login
Sidebar selection – Development – Development Settings – Applets code upload
Then add the public IP used to build the machine and download the private key to save it. I’m going to use it later.
2. Jenkins Settings
Jenkins uses parametric builds, adding multiple drop-down parameters.
There’s a little pit here.
As mentioned, we are a set of code for multiple applets distribution, all the same except for some channelization parameters. However, the parameters of channeling are a little too many and need to be matched one by one.
Because unlike the front end of Jenkins, the display of the drop-down box is key, and the real value is value. Instead, key-value is always the same value. So if all parameters are made optional, it is necessary to send the package personnel to check one by one, that the version is too uncomfortable.
Our expectation is that you can send a package by selecting one option – client body.
So I took a different tack here (it might seem simple, but I was thinking about it for a long time, and it hit a dead end). I write all the required values in the display dropdown, the first value is the customer name, with; Do the delimiter, and finally cut the string in the shell to get the required packaging parameters.
I coded sensitive information in the picture, and you can see it’s a dropdown
Select the customer. The configuration and effect are as follows
During the build process, use the CI tool to do the upload.
#! /bin/sh
# No Spaces on either side of the equals sign
# -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- assignment -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
echo "Assignment operation"
hospitalName=`echo ${hospital} | awk -F ";" '{print $1}'`
http_env=`echo ${hospital} | awk -F ";" '{print $2}'`
fileName=`echo ${hospital} | awk -F ";" '{print $3}'`
appid=`echo ${hospital} | awk -F ";" '{print $4}'`
#------------------ pull rely on ------------------
echo "Pull dependence"
cd ./internetHospital
npm install
#------------------ Perform the build ------------------
echo "Perform the build"
npx cross-env http_env=${http_env} fileName=${fileName} hospitalName=${hospitalName} node build/build.js wx
#------------------ Perform upload ------------------
echo "Perform upload"
npx miniprogram-ci upload --pp ./dist/${fileName}/wx --pkp ./privatekey/private.${appid}.key --appid ${appid} --uv ${version} -r 1 --enable-es6 true
echo "Uploaded."
Copy the code(In fact, you might want to focus on step 4 uploading, and step 3 building is also recommended) :
Step 1 assignment:
It’s me parsing the values of the parameters I need to pack, and you may not need them, or they may be different.
Step 2 pull dependency:
This is nothing to say, go to the code folder and pull dependencies.
Step 3 Perform the build:
This step is a package command written by my colleague. The MPvue we use needs to do a package operation. The product is a small package that can be uploaded.
However, NPX and cross-env should be noted in this step, which can be read at the end of the article.
Step 4 upload:
That is to call wechat miniprogram-CI, and how to obtain appID was also mentioned earlier. I put it all in Jenkins’ drop-down parameters. As for the private key, I put it in the project directory, so git can get the private key after pulling it. How to obtain the private key, you can do your own tricks.
Results:
npx
NPX can help extract command soft links from tools used in projects. For example, if you download ESLint in a project, it’s not installed globally. To run eslint, you need to go to node_module/eslint/bin to find eslint, or NPX. (This is useful when using wechat miniprogram-ci. I don’t want to install miniprogram-ci globally on Jenkins’ host.)
You can also install some modules in your local, temporary download remote module call, you can add parameters after the call to delete. (Again, cross-env is used for this purpose without having to install the host globally.)
cross-env
Run scripts that set up cross-platform and use environment variables
The resources
Jenkins continuous integration
Self-made GUI page to complete the small package release