[Jenkins Advanced]-Back-end CI/CD

What is backend automation

Back-end automation does not mean automatically generating code, but automatically building projects.

If there is no automation, our back-end workflow from development to testing may be as follows:
1. Write code on the local machine
2. Submit the code, push to the git remote warehouse
3. Perform the mvn clean package unit test and package the jar package
4. Various methods such as ssh/ftp sending packages to the test server
5. Restart the java service
In this process, each step has to be repeated manual operations, which greatly increases the time cost. For the results of unit testing or packaging, there is no automatic feedback mechanism, and the running results need to be manually verified. The final deployment is also to manually log in to the server to execute the script, which is very cumbersome.

introduces automation, the whole process becomes:
1. Write code on the local machine
2. Submit the code, push to the git remote warehouse
3.Git hook triggers the construction of jenkins job
4. Pull the project code in jenkins job and run mvn clean package or mvn clean package -Dmaven.test.skip=true
5. Execute the deployment script of the test server in jenkins job
In the automated process, only step 1 and step 2 require manual operation, and the other steps are automatically run. It is a very standardized process, which reduces the risk of manual operation and eliminates repetitive work.

accomplish

flow chart

• Developers submit code to the code base
• Trigger jenki build task
• The build is successful, the jar package is sent to the server, the restart script is executed, and the service update is complete
• Build failure, remind developers of code build failure through DingTalk notification/Enterprise WeChat/Email, etc.

1. Preparation:

Prepare git project: https://github.com/wzc570738205/backendproject.git
Prepare nail group (used to receive CI/CD result notification): 35669766
Ready to install the cloud server here, refer to on the linux server

2. Notification of access code submission

When you push the code to the code base, automatically send a message to Dingding through the git webhook

2.1 Add Dingding Group Robot (Smart Group Assistant)


Copy webhook, you will use it next


2.2 Add Dingding webhook to the corresponding webhook corresponding to github

2.3 Notification of test code submission

Configuration is complete, we submit the code for testing


far, the code submission notification configuration is complete

3. Access project CI

After we submit the code, we need to check whether there are fatal errors in the code merge. Here we take a simple method to allow mvn clean package . If there is no error, then the submission is passed. Failure means that the code has a fatal error and needs to be modified

3.1 Jenkins new project

Install plug-in Maven Integration plugin

• Create a job to build a maven project
• 
• The source code manager selects git, and fills in the address and credentials (create a new one if not)
• Build trigger selection: GitHub hook trigger for GITScm polling

• Build environment:

• 

   clean package -Dmaven.repo.local=/var/jenkins_home/.m2/repository -Dmaven.test.skip=true

• Post-build operation (optional):


We use jenkins job execution success and failure to determine whether CI is successful

3.1.1 Test

Submit the code again and successfully trigger the jenkins job


Successfully built


3.2 Dingnail notification of access construction status (this is the same as front-end access, and will not be explained here)

• Configure Dingding custom robot, and select security settings custom keywords, here you can #

• Download the jenkins plug-in DingTalk for nail notification

• Configure plug-in=>System management select Dingding, fill in the custom robot webhook address just now


• Turn on robot notifications in the project


• Click to start building and test

  
Wait for CI to end

Failure reminder


far, the CI configuration is over, we have implemented the code submission nail reminder, and the CI notification reminder

4. Access CD

In the above steps, we implemented the CI operation, that is, whether the package of the generation environment can be packaged to suggest whether the code has fatal errors. After this step is passed, we need to send the deployment package to the nginx server

4.1 Send package to server

• Install the jenkins plugin Publish Over SSH
• Configure the plug-in in the settings, fill in the server ip, use the password in the advanced, and set the remote server folder /

Click to test connectivity

• Add post-build operation 0614a863775237, and execute the restart service shell Send build artifacts over SSH

shutdown.sh

#! /bin/shell

# 项目名称
APPLICATION="测试端"

# java路基
JAVA=$(which java)

# 项目启动jar包名称
APPLICATION_JAR="compreDisplay_backend-0.0.1-SNAPSHOT.jar"

PID=$(ps -ef | grep "${APPLICATION_JAR}" | grep -v grep | awk '{ print $2 }')
if [[ -z "$PID" ]]
then
    echo ${APPLICATION} is already stopped
else
    echo kill  ${PID}
    kill -9 ${PID}
    echo ${APPLICATION} stopped successfully
fi

startup.sh

#! /bin/shell

# 项目名称
APPLICATION="测试后端"

# java路基
JAVA=$(which java)

# 项目启动jar包名称
APPLICATION_JAR="compreDisplay_backend-0.0.1-SNAPSHOT.jar"

nohup $JAVA ${JAVA_OPT} -jar /applocation/backend/compreDisplay_backend/${APPLICATION_JAR}

At this point, the CD integration is complete, now only need to submit the code, you can achieve automatic packaging, automatic deployment and restart the service.

Concluding remarks

I will continue to write how to access gitee, gitlab, and svn in the future.