Jenkins is often more than a tool for starting a build. In a typical DevOps workflow, it may need to check source code out from Git, compile the project locally, package the result, and deliver the artifact to a test or production server. If the workflow also includes publishing custom Docker images, Jenkins requires additional environment and credential configuration.
This walkthrough uses a Java project named api-gateway-demo as an example. The repository can be hosted on GitLab, Gitee, or GitHub. The process begins with a basic freestyle job and gradually adds source checkout, Maven compilation, and remote delivery.
Creating the Jenkins job
Make sure the project is already available in the Git repository, then open Jenkins and create a new item from the left-hand navigation.
Choose Freestyle project as the job type.
A freestyle job is sufficient for this initial configuration and can later be extended with parameterized builds, deployment steps, or other pipeline features.
Connecting the job to the Git repository
Jenkins must check out the repository to the local disk used by the Jenkins service. In the job configuration, add the repository URL under the source-code management section and provide the required credentials if the repository is not public.
Save the job, then select Build Now from the demo project page.
After the build starts, select the corresponding build entry to open its console output.
The log confirms whether the source was checked out successfully. It also shows where Jenkins placed the working copy. In this example, the project is available inside the Jenkins container at:
/var/jenkins_home/workspace/demo
The workspace is the directory Jenkins uses for subsequent build steps, so Maven commands executed by the job will run against the checked-out project there.
Preparing Java and Maven
Once the source is available locally, Jenkins needs a Java runtime and Maven environment to compile the project. Prepare the JDK and Maven archives, then map them into the Jenkins container through a volume so that the service can access them.
Extract the archives and configure Maven's settings.xml. The following configuration sets a mirror and defines the compiler settings for JDK 1.8.
<!-- 阿里云镜像地址 -->
<mirror>
<id>alimaven</id>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<mirrorOf>central</mirrorOf>
</mirror>
<!-- JDK1.8编译插件 -->
<profile>
<id>jdk-1.8</id>
<activation>
<activeByDefault>true</activeByDefault>
<jdk>1.8</jdk>
</activation>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
</properties>
</profile>
In Jenkins' global tool configuration, add the JDK and Maven installations and save the settings.
Return to the job configuration and add the Maven build step. Select the JDK and Maven installations configured above, then save the job.
Run the job again to verify the build. After a successful Maven build, the generated JAR should be available in the project's target directory.
Delivering the JAR to another server
After the artifact has been built, it can be copied to a test or production host. This setup uses the previously installed Publish Over SSH plugin to connect Jenkins with the target environments.
First, configure the SSH connection information for the test and production servers in the Publish Over SSH settings.
Next, open the job's Post-build Actions and add the step for transferring the generated JAR to the selected target server.
At this point, the job can check out the code, build the Java project, and deliver the resulting JAR to a remote server. That completes a basic build-and-delivery workflow.
Selecting a release with a Git tag
Continuous delivery is closely related to continuous integration, but it normally needs to deploy a specific release rather than whichever commit happens to be at the tip of a branch. To select a tagged version when starting a job, install the Git Parameter plugin.
After installation, enable parameterized builds for the project and add a Git-based parameter. Configure the parameter to obtain the available versions from Git tags.
Create a version tag for the project, then use a shell build step to check out the tag selected for the current build. The deployment job can use that parameterized version to publish the chosen release to the target server instead of always building the latest branch state.
This arrangement gives Jenkins a simple but complete delivery path: retrieve the repository, build it with the configured JDK and Maven environment, choose a release when needed, and transfer the resulting package to the selected environment.