After six or seven simultaneous projects and frequent release tests, I’ve had to learn a few lazy tricks to improve efficiency, so this article will focus on how to optimize the release process.
After the build, FileZilla was used to upload the server to complete the deployment. After the front end is packaged, git push is performed in the build repository and the back end is deployed automatically. The automatic deployment of the backend does simplify a lot of operations, but for the front end, the need to go to the build repository to perform the push operation every release, especially when the release is frequent, will inevitably reduce efficiency, this kind of repeated operation is better for the script execution. So the next step is to focus on how to complete the project release by simply executing the NPM run build.
(This article is based on the Windows system and Node environment, each system scripting language may be error, the basic idea remains the same)
This paper is divided into two parts, the first part is mainly about the front-end packaging optimization process, the second part briefly introduces the principle of automatic deployment of the back-end.
One: front-end release optimization
First of all, it should be made clear that the build process of most front-end projects is based on node environment, so the main idea of optimization process is to use Node to interact with the operating system and call system scripts to complete file copy and Git operations. Here we need to understand what happens when NPM run build is executed. NPM run build is just a syntax sugar,
inpackage.json
You can see that node is used to executebuild/build.js
File, let’s rewrite itbuild
To make it easier to compare, I’ll paste the “before and after” build file here.After the rewrite:
We don’t have to read all of what’s going on in build.js, we just need to know where to execute our script after a successful build. We can clearly see the webpack callback function, and when we find the location, we need to import children_process, There are two things to say about this module:
Exec (commad,options, children_process); children_process (commad,options, children_process); Callback), the main function is to create a shell and execute commands in the shell. After execution, pass stdout and stderr as arguments to the callback method. Check out the Node documentation for more details
Process. argv[1] is build.js, and process.argv[1] is build.js, and process.argv[1] is build.js. Process. argv[2] is a, and so on.
With these two points in mind, we can design our custom commands, because the purpose of optimization is to simplify operations, so we attach our custom parameters during build, which is related to our script writing later. NPM run build (push) (commit) (branch)
1. Push indicates whether the package is directly pushed to the remote.
Git commit -m ‘(commit info)’;
Git push origin (branch) is the branch where git push origin (branch) is distributed to a formal server or a test server
After customizing the parameters, we use them in the callbackexec()
Execute our script
At this time, we will write our script. We will create a new autopush.bat file and put it in our root directory. The script content is very simple, probably copy, paste, delete and git operations
cd D:\build\testGit checkout %2 */ rd /s/q D:\build\test\static /* Delete the build repository static folder */ xcopy D:\source\test\dist D:\build\testGit add. Git commit -m %1 / git push origin %2 / git push origin %2 / git push origin %2 / git push origin %2 /cd D:\myFolder\31abc_adminCopy the code
Here are three points:
If you do not delete the static build file, the js file name will change. If you do not delete the static build file, the JS file name will not be overwritten.
2. The window script parameters are obtained from %1, for example, %1 to get the first parameter and %2 to get the second parameter, so that we can get the commit and branch parameters passed in when executing the script in build.js.
3. About the meaning of parameters in deleting and copying,
Rd /s/q /s deletes all traversed subdirectories and files in the directory. /q Deletes the /E/I/Y /E following xcopy without prompting confirmation. Copies all subdirectories, including empty directories. /I If "Source" is a directory or contains wildcards and "Destination" does not exist, "Xcopy" assumes that "Destination" specifies the directory name and creates a new directory. Xcopy then copies all specified files to the new directory. By default, "XCopy" will prompt you to specify whether "Destination" is a file or directory /y disable prompt to confirm overwriting an existing target file.Copy the code
After the above operation, we can complete the packaging to push operation through the NPM run build push master line command. At this time, if the backend is set to automatic deployment, then, it will be directly online.
Two: Automatic back-end deployment
There are a lot of articles about automatic deployment on the Internet. Here is a brief introduction to the principle of automatic deployment to match this article. The key to automatic deployment lies inwebhook
, major code hosting platforms have this feature, includingCoding, making
Github, for example, is around this location
After filling in, the repository will listen for push operation. Once push operation occurs, Webhook will send a POST request to the interface you set, and then execute script on the server side for Git pull operation. Pull down the latest code, and deployment is complete.