After the deployment, we began to conduct in-depth research on the functions of jenkins. First, we are familiar with the use of git parameterized construction of jenkins, which can help us better update and roll back the version in time.
First of all, we need to prepare the xml code file in the warehouse for testing. As shown in the figure, it is ready. If there is no package, private message me that the cloud server has expired, and it was originally placed on the cloud.
Next we need to install the plugin "Git Parameter". as shown in the picture
After downloading, test it manually
[root@git-client ~]# git clone [email protected]:jingchao_1/benji.git
[root@git-client ~]# cd benji
[root@git-client cloudweb]# vim src/main/webapp/index.jsp
[root@gitlab easy-springmvc-maven]# git add *
[root@gitlab easy-springmvc-maven]# git commit -m "Change user to password"
[root@gitlab easy-springmvc-maven]# git tag -a "v1.0" -m "Change user to password"
[root@gitlab easy-springmvc-maven]# git tag #Check out
v1.0
[root@gitlab easy-springmvc-maven]# git push origin v1.0
go Check the warehouse to see if the label has changed
Configure Jenkins parameterized build (tag mode)
After the build is successful, you can modify the push version number and push it again to see if there is a new version number on this page. If there is, it is successfully built using the git tag parameter.
Access test: In this step, there is no need to do it if there is no package
Configure Jenkins parameterized build (commit revision number)
If developers don't know how to tag, or they are unwilling to cooperate with tagging
The operation is basically the same as the tag operation, just modify individual parameters
Other operations are consistent with the tag, so I will introduce it to you today,
Tomorrow, I will update the multi-node configuration of jenkins for everyone.
See you tomorrow.