Automate Java Deployments with Docker and Jenkins in Four Simple Steps

1. Continuous Deployment Technical Idea

Assume a Java project named hello. The source code resides on a Git server, while Jenkins and a private Docker Registry run in separate containers; the Java application itself runs in its own hello container. The deployment pipeline pulls the latest image from the private registry and rebuilds it, with Jenkins acting as the central orchestrator that responds to Git push events by executing remote shell scripts.

Directly mounting host code into containers is discouraged because it breaks the container‑as‑a‑package principle, increasing complexity and reducing the benefits of true container isolation.

Containers should be treated as short‑lived processes; when an issue occurs, the container is terminated rather than repaired.

2. Result Demonstration

2.1 Before Code Update

Timestamp displayed on the homepage shows the current version.

2.2 Submitting a Code Update

The timestamp is changed from 201506181750 to 201506191410.

2.3 Pushing New Code to Git

Enter the Git credentials and push the changes.

2.4 Viewing the Updated Result

After a short wait, the new code is automatically deployed and the updated timestamp appears.

3. Configuring Git and Jenkins Integration

3.1 Jenkins Git Source Configuration

Create a Jenkins job named java-app and set the Git repository as the source.

3.2 Jenkins Remote Build Configuration

Generate a token in Jenkins for remote triggering from Git.

3.3 Enabling Git Hooks

Configure a Git post‑receive hook to notify Jenkins of new commits.

4. Configuring Jenkins Automatic Code Update

Jenkins receives the Git hook, triggers a remote build on the target server, executes a predefined script sequence to rebuild the Docker image, and pushes the new image to the private registry.

The essential shell script (shown in the original images) performs Docker login, builds the Maven project, creates a new image, pushes it, and restarts the container.

5. FAQ

Q1: Why not mount code from the host for Java projects, and could this work for PHP?

A1: Extracting code from the container violates container principles and adds complexity. The same approach can be used for smaller projects, but keeping code inside the image preserves consistency.

Q2: What if the codebase exceeds 500 MB or 1 GB?

A2: Very large codebases indicate the need for architectural changes; containers are not intended for such massive payloads.

Q3: In production, should each container contain the full code or use shared storage with lightweight base images?

A3: While shared storage can reduce image size, it reintroduces host‑dependency issues. Containers should remain self‑contained to ensure environment consistency and simplify scaling.