Operations 10 min read

A Complete Jenkins + Maven + Git Automation Deployment Guide

This article walks through setting up three servers (GitLab, Jenkins, and a test machine), creating a GitLab project and token, configuring Maven and Jenkins plugins, defining Git, branch, and Maven settings, and implementing pre‑ and post‑steps—including a cleanup script and SSH publishing—to automatically build and deploy a Spring Boot JAR, while addressing common pitfalls such as missing manifest attributes and port conflicts.

Java Companion
Java Companion
Java Companion
A Complete Jenkins + Maven + Git Automation Deployment Guide

Prerequisites

Three servers are required: a GitLab server (gitlab99, 192.168.40.99, 8C8G, running GitLab), a Jenkins server (jenkins98, 192.168.40.98, 4C4G, with Jenkins, JDK, Maven, Git installed), and a test server (test97, 192.168.40.97, 2C2G, with JDK).

Environment Setup

In GitLab a new group and a blank project are created, and a personal access token (e.g., glpat‑qx7VU3J219j1D4_92uqJ) is generated under Preferences → Access Tokens . In IntelliJ IDEA a new Spring Web project is created, the server port is set to 8088, and a simple @RestController returning "Hello dev" is added.

Jenkins CI/CD Configuration

1. Install the Maven plugin via

Dashboard → Manage Jenkins → Manage Plugins → Available

and search for "maven". 2. Create a new Jenkins job (Item) and configure the Git repository URL with the generated token. 3. Set the branch to build, then configure Maven by pointing to the Maven installation path at http://192.168.40.98:8080/configureTools/ (Root POM remains jenkins‑study). 4. Add a post‑step using the SSH Publisher plugin to copy the built JAR to the test server. 5. Define a pre‑step that runs a cleanup shell script ( clean.sh) on the test server to kill any existing Java process, remove old JARs, and clear the target directory. Example clean.sh :

#!/bin/bash
appname=$1
if [ -z $appname ]; then
  echo "Application name cannot be empty!"
  exit -1
else
  echo "Application name is $1"
fi
# Remove old JARs
rm -rf $appname/*.jar
# Find running PID
pid=$(ps -ef | grep $1 | grep 'java -jar' | awk '{printf $2}')
if [ -z $pid ]; then
  echo "$appname is not started"
else
  kill -9 $pid
  echo "$appname was stopped"
fi

The post‑step runs the command:

nohup java -jar /root/jenkins‑study/jenkins*.jar >> /root/jenkins‑study/log.out 2>&1 &

Explanation of the redirections is provided in the article.

Testing and Cleanup

After saving the configuration, trigger a build. The console output shows the JAR being packaged in /root/.jenkins/workspace/first/target/ . The JAR is then transferred to the test server, where it is started with the nohup command. Common errors such as "no main manifest attribute" are resolved by setting spring‑boot‑maven‑plugin skip to false . Port conflicts (e.g., 8088 already in use) are handled by cleaning the previous process before each build. Verification steps include running jps on the test server to confirm the new PID and checking /root/jenkins‑study/log.out for successful startup.

Conclusion

The guide demonstrates a complete Jenkins‑based CI/CD pipeline that pulls code from GitLab, builds a Spring Boot JAR with Maven, and deploys it to a remote test server via SSH, while incorporating pre‑build cleanup to avoid stale processes and port collisions.

CI/CDAutomationGitmavenshellJenkins
Java Companion
Written by

Java Companion

A highly professional Java public account

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.