Automated Deployment of Java Projects Using Jenkins Pipeline

The article continues a series on deployment automation, focusing on implementing a fully automated Jenkins Pipeline for Java backend projects. It begins with an overview of pipeline concepts, advantages such as parameter support, version control, collaboration, and reusability, and also notes drawbacks like learning curve and complexity.

It then describes how to create a Pipeline job in Jenkins, showing the basic structure with pipeline, agent, stages, stage, and steps sections. A sample skeleton is presented:

pipeline{
    // specify the node
    agent any
    // define stages
    stages{
        stage("CheckOut") {
            steps {
                script {
                    echo "获取代码"
                }
            }
        }
    }
}

The deployment workflow is detailed: Jenkins runs on a server with necessary plugins, pulls code from GitLab, builds the Java project with Maven, copies the JAR to a remote server, backs up the existing JAR, updates the new JAR, and finally restarts the Docker Swarm services.

Parameterization is demonstrated using parameters to let users select the GitLab branch ( GIT_BRANCH) and the micro‑services to deploy ( SERVICE_NAME) via the Extended Choice Parameter plugin. Environment variables such as GIT_URL are defined in the environment block.

pipeline {
    parameters {
        string(name: 'GIT_BRANCH', defaultValue: 'dev-01.30', description: '请选择部署的分支')
    }
    environment {
        GIT_URL = 'https://xxx/xxx.git'
    }
    // other stages ...
}

Key stages include:

Fetching the latest code from the selected branch using the checkout step.

Compiling the project with Maven via a Windows bat 'mvn clean package' command.

Uploading the generated JAR files to the remote server using the sshPublisher plugin, iterating over the selected services.

Backing up existing JARs on the server by creating timestamped directories and moving old files.

Updating the JARs by moving the newly uploaded files into their final locations.

Restarting each micro‑service with sudo docker service update --force <service> executed remotely.

Each of these steps is illustrated with concrete Groovy snippets wrapped in script blocks, showing how parameters are accessed (e.g., params.GIT_BRANCH) and how SSH commands are constructed.

The article concludes that using a Jenkins Pipeline for backend deployment offers greater flexibility and encourages storing pipeline definitions in version‑controlled repositories for easier management.