Small program automation
why
Why do small program automation?
If we simply say why we do it, it’s probably official, CI/CD, automation, blah, blah, blah, blah, BLAH. I think the reverse answer would be a little more vivid, what if we don’t automate? Take a look at some of the problems in the development of these applets.
Monkey A was happily developing A function, when suddenly one of the product students came to see B function. I asked you to give me the experience code of A small program. The requirements were very reasonable. Then git checkout, Git Stash pop, roll up your sleeves. Right now you should feel nothing, usually do so, that is, a few minutes of things, delay up. Too young to simple! Next look at this, at this time the test students came again, want to test how C function development, and give a code package, can be imported into the developer tool for testing, the same reasonable request, can not refuse, then repeat the above operation, I can endure.
Keep reading!
Now, two more test students need you to give the code of function D and function F, what do you do? Waiting in line, then coding, the time should have passed at least nearly dozens of minutes, when you finished all these, ready to enter happy coding again, the first test student came to tell you, why do you not have some functions just launched in this version? Remember, your branch hasn’t synchronized with the master yet! Then you synchronize the code and repackage it. In this way, one morning may have passed, and your happy coding is still in a View tag you just wrote, without even a className! At this point, you remember, there is a function that needs to be raised now, to be continued…
If you’re working on a tricky bug, the four preview codes should have already caused you to lose your train of thought, and some of the preparatory work is already cold, so you might have to start over again. If you make a few more of these requests, I guess you’re on the verge of breaking down. In the above process, 80% of your time is still waiting for the build, small application upload, such a waste of time, very shameful!
The above example, should be in the process of small program development, we will encounter problems, colleagues’ needs are reasonable, you do is reasonable, but your time is so unreasonable in the past. To sum up, let’s formally summarize some problems that may occur if automation is not used.
- Branch switch, code upload, preview code generation, mindless but time-consuming operation
- When the code generation request comes in at the same time, it needs to wait
- The independent mechanism of small programs makes it impossible to control the overall process as on the Web
- The process by which non-developers get experience codes depends on developers
how
How can we solve the situation
To introduce the topic, we should use machines to replace human beings to complete repetitive work, and standardize human processes through machines to reduce human error rate (as we all know).
Take wechat mini program as an example, the official NPM package provides the function of uploading preview, which is used to solve the manual click problem of developer tools. To build process tools, we chose Jenkins. We want to carry out some detection mechanisms similar to those on the Web side, but this layer mechanism is cumbersome to write on the Jenkins side, and the front-end knowledge of Jenkins is not enough, so a layer of Node is added to solve the problem of process control.
In addition, we also lack a trigger mechanism. When does a build trigger?
- We can do this based on hooks provided by GitLab, but this solution requires some dependencies such as commit commit, Mr, etc. Normally non-developers do not have Git permissions, so this is limited. If the branch is not modified, we also want to package it, which is also limited here
- We can also make tool platform, need on the tool platform for building, however, tool platform development, to consummate the permissions page such as operation, and maintenance is more trouble in the late, here is not suitable for, because we want to do a small, beauty tools, application platform for more time, and need to put in the extra manpower cost.
Dingding was used for all of our internal work, and dingding provided the robot, which made our trigger mechanism easier to start with. Therefore, the follow-up process can be as follows:
- The build is triggered by the stapling instructions
- The node end is used as the intermediary to complete process operation
- Jenkins side for packaging upload preview and other time-consuming operations
- Call back to the Node side to beautify the original information
- Nailing receives node information and feeds back to users
what
How to do
Nailing robot document
Document content, you can view (programmers are genius documents) we can directly @ nail robot, input instructions
The request body received from the nail end is as follows:
Received is a string, we use a CLI-like format to parse the parameters, so that we can do some configuration operations on the Node side, and the other two parameters are used for reply and role judgment.
Because Jenkins has operations such as container creation and startup, which are time-consuming and cause resource queuing problems, users can be notified first that Jenkins has responded, namely, the container is being started above.
At this time, we can carry out corresponding operations according to the command parameters, pull the branch code of the corresponding project from Jenkins side, and then go through the process of packaging and construction. After the construction is successful, the products can be temporarily stored in OSS.
After the successful construction, options preview and download, users can click the preview function for multiple preview code generation operation, download can provide source code, server-side students or test students, you can download the product code, import developer tools for joint adjustment or test. After successful construction, the preview code will be generated automatically.
Each step notifies the user of the current status of the process to avoid confusion about where the process is going.
The preview is successful
As an intermediary, the Node end completed the information flow between Jenkins and the nail end, and also made some process control and optimization strategies.
- Before building, the branch is checked to see if it is in sync with the Master branch, and if it is not, it is forced to be. This restriction is intended to avoid rework problems caused by test students testing unupdated code
- Build lock, if @ robot builds the unified branch multiple times, subsequent builds will not take place, when the build is complete, release the lock to avoid some unnecessary builds
result
The tool took about 2 days to develop and ran stably after a week. At present, it supports three small programs and 50+ colleagues in production and research. It has supported the release of consumer business for 7 months.
The only drawback is that it is used for building data statistics, so you understand.
Write in the last
Through this small and beautiful tool, we greatly improve the development and testing efficiency, but also ensure that the small program side also has a certain process control. In the whole process, the pain points in the business are solved through the existing knowledge reserve.
And the whole tool development process, encountered problems, solve the problem, step by step to improve the tool, to solve the business pain points. This is an example of how to improve yourself in business.
This article is not a direct copy to complete the application, but a problem solving process. How to choose, how to improve the input-output ratio.
If the article is not appropriate, welcome guidance ~
Welcome to pay attention to the public account, the green vegetable garden of cabbage bug, the follow-up will be updated regularly
Article on official account