1.Introduce the background
Git is usually used to manage the project during project development.
Git is even more important when multiple people develop projects together.
Because the project is relatively private and cannot be made public, the project team uses GitLab's private server and
everyone develops on the development branch (occasionally an independent branch is required) )
After the development is completed, test it yourself first. If there are no basic problems, then submit it to the test branch.
1.1 Previous process
- Front-end manual packaging - log in to the test server - submit to tomcat or nginx directory
- Backend manual packaging - Log in to the test server - Stop the original project - Submit to the directory - Run the project
After repeated several times, this process is very cumbersome, and sometimes the packaging is not successful and the code is not updated.
Therefore, this part should be replaced by a machine. Here, Jenkins was chosen to help integrate the project.
1.2 Current process
- The front end is submitted to the test branch after the development of the dev branch is completed.
- The backend is submitted to the test branch after the development of the dev branch is completed.
All subsequent work is handed over to Jenkins.
1.3 Integration process
- Pull the specified branch from the Git repository
- Switch the corresponding version (Node, Java)
- Check code dependencies
- Package the project
- Execute Dockerfile
- Submit Docker image to Harbor
- Notify Rancher to update the project
- Static code scanning
- Issue scan reports and results
- Notify PingCode (agile platform) that the integration is completed (including branch status and deployment status)
- CI/CD completion email notification (currently turned off, too annoying)
The current article only covers project packaging
The remaining steps are in other articles
1.4 Current results
Currently, many projects are managed by Jenkins
, and there is a set of continuous integration processes behind them. In the end, the projects will be run on K8s (some small and old projects are still managed by docker-compose). The following
is a project view through Jenkins showing that there are already many projects. Project
1.5 Prerequisites
Requires your environment to already have
- Jenkins
- GitLab
- Project branch
2. Server project configuration
First log in to the server and create a folder to store the project.
The name of the file is arbitrary but it is best to know the name (in my case it is docker-{project name})
Here I take the scaffolding packaged by myself in GitLab as an example (SpringBoot project).
I created a new one: test-template.
Since this project is a back-end project, I created a new backend folder under test-template.
usepwdCommand to record the current path
当前的路径是：/home/test-template/backend
This folder will contain the source code of the project on GitLab
3.Jenkins project configuration
3.1 New project
Log in to Jenkins and selectNew Item
3.2 Fill in the information
The project name is the rule test-template-backend in the folder just now.
It identifies it as the backend of this project.
ClickOK
3.3 Configuration comments
fill inDescription
The description of the project can be as detailed as possible to facilitate maintenance.
ClickAdvanced
3.4 Configuration folder
After clicking Advanced,
the following will pop upDirectory
Fill in the directory just recorded on the server
3.5 Pull Git address
Configure the GitLab project address
. Note that the address must be.gitfinal
3.6Git branch
Configure the branch to pull the source code. The configuration here is*/test
3.7 Turn on WebHook
Check:Build when a change is pushed to GitLab …
Copy the webhook URL: http://172.16.1.150:10101/project/test-template-backend (each project is different!!!)
The following interface will appear
. ClickAdvancedMake detailed configuration
3.8 Configuration branch
To select the listening branch, I chose regular matching here..*testbranch
3.9 Configure the secret key
ClickGenerategenerateSecretToken
3.10 Execute script
chooseBuild
ClickExecute Shellto execute the shell script
There are several options here
- Put the Shell into the project and follow the project (the advantage is that you can also submit the Shell and modify it at any time)
- Put the Shell on the server (the advantage is that the person who handed over the safe branch does not have permission to modify the packaged instructions)
- Shell is placed in Jenkins (the advantage is that people who are not convenient to operate the server can operate the instructions to be executed)
3.11 Writing instructions
Fill in the Shell command you want to execute.
Since the service needs to be stopped and started again,
you can try to kill the service first and then execute java -jar.
My plan here is to package it into Docker in the subsequent operation and then push it to the K8s cluster according to the process.
You can do this step yourself
3.12Save project
Click on the bottomSave
First test whether the configuration is effective
3.13 Test integration
ClickBuild Now
Make sure the project on GitLab hastestBranch ha! !
3.14 View results
can be seen#1、#2Successful.
You can try to click on #1 #2 to view
3.15 View server
Looking at the file, you will find that Jenkins has helped us pull the project down
andtargetDirectory tooJenkinsimplementmvnPackaged directory
4.GitLab project configuration
Open GitLab project
SelectSettings
chooseIntegrations
4.1 Configure Webhook
fill inURL
Fill in the Webhook address of Jenkins just nowSecretTokenThe secret key generated for the button in Jenkins
4.2 Add Webhook
ClickAdd webhook
4.3 Test notification
ClickTest
choosePush Events
Click to see if GitLab can notify Jenkins through WebHook normally
4.4 Normal notification
See:HTTP 200
This shows that GitLab can now notify Jenkins normally.
5. Test the whole
At this point, submit the code to the test branch of the project in GitLab.
A WebHook will be issued to trigger Jenkins
to complete the command in the Shell
. This completes the basic CI/CD. For
more complex integration, please check other articles on the blog.