CI/CD for Java Developers

What is CI/CD — and Why Does It Exist?

Before CI/CD, shipping a Java change meant building it on your own machine, and then manually copying the artifact to a server — SCP, FTP, or a shared drive — and restarting the process by hand. Every deploy depended on whoever's laptop built the jar: their exact JDK version, their exact dependency cache, whatever uncommitted local change happened to be sitting in their working directory. "It works on my machine" wasn't a joke; it was the actual deployment process.

// BEFORE — manual build and deploy, different every time
$ mvn package                      # on YOUR laptop, with YOUR local Maven cache
$ scp target/order-service.jar deploy@prod:/opt/app/
$ ssh deploy@prod "systemctl restart order-service"
# Did staging get tested with this exact jar? Unknown.
# Did anyone else's uncommitted change sneak into this build? Unknown.

// AFTER — one pipeline builds it once, the same artifact moves through every stage
// git push triggers: compile → test → package → the SAME jar is
// promoted through staging → production. No laptop involved, ever.

CI/CD from a Developer's Seat — What's Actually Your Job

It's easy to hear "CI/CD" in standups and file it under "that's a DevOps thing." In practice, on most teams building services like order-service or customer-service, the split looks like this — and the boundary shifts with team size, but the categories stay useful:

The CI/CD Pipeline — Stage by Stage

Source → Build → Unit Tests → Static Analysis → Package → Integration Tests → Deploy Staging → Deploy Production

GitHub Actions for Java

Basic build and test workflow

# .github/workflows/build.yml
name: Java CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

# Least-privilege by default — grant only what this workflow actually needs
permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-java@v4
      with:
        java-version: '21'
        distribution: 'temurin'
        cache: maven

    - name: Build and test
      run: mvn -B verify

Multi-version testing

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        java: [17, 21]
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-java@v4
      with:
        java-version: ${{ matrix.java }}
        distribution: 'temurin'
        cache: maven
    - run: mvn -B verify

# Fragile — the code that runs can change without your workflow file changing
- uses: some-org/some-action@main
- uses: some-org/some-action@v4

# Pinned — this exact commit's code is what runs, always, until you
# deliberately bump it
- uses: some-org/some-action@8f8f8f8f8f8f8f8f8f8f8f8f8f8f8f8f8f8f8f8f # v4.2.1

Docker build and push

name: Build and Push Image

on:
  push:
    tags: [ 'v*' ]

permissions:
  contents: read
  packages: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-java@v4
      with:
        java-version: '21'
        distribution: 'temurin'
        cache: maven

    - name: Build with Maven
      run: mvn -B package -DskipTests

    - name: Log in to registry
      uses: docker/login-action@v3
      with:
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}

    - name: Build and push
      uses: docker/build-push-action@v6
      with:
        context: .
        push: true
        tags: ghcr.io/shop/order-service:${{ github.ref_name }}

Jenkins Pipeline

Jenkins is the most widely used self-hosted CI/CD server — maximum flexibility and control, at the cost of you (or a platform team) maintaining the server itself.

// Jenkinsfile in project root
pipeline {
    agent any
    tools {
        maven 'Maven-3.9'
        jdk 'JDK-21'
    }
    stages {
        stage('Build') {
            steps { sh 'mvn clean compile' }
        }
        stage('Unit Tests') {
            steps { sh 'mvn test' }
            post { always { junit 'target/surefire-reports/*.xml' } }
        }
        stage('Package') {
            steps {
                sh 'mvn package -DskipTests'
                archiveArtifacts artifacts: 'target/*.jar'
            }
        }
        stage('Deploy to Production') {
            when { branch 'main' }
            steps {
                input message: 'Deploy to production?'   // manual gate — Continuous Delivery, not Deployment
                sh './deploy.sh production'
            }
        }
    }
}

Parallel stages — independent work runs concurrently

stage('Tests') {
    parallel {
        stage('Unit Tests')        { steps { sh 'mvn test -Dtest=*UnitTest' } }
        stage('Integration Tests') { steps { sh 'mvn verify -Dtest=*IntegrationTest' } }
        stage('Coverage')           { steps { sh 'mvn jacoco:report' } }
    }
}

GitLab CI/CD

# .gitlab-ci.yml
image: maven:3.9-eclipse-temurin-21

cache:
  paths:
    - .m2/repository/

stages:
  - build
  - test
  - package
  - deploy

unit-tests:
  stage: test
  script:
    - mvn test
  artifacts:
    reports:
      junit: target/surefire-reports/TEST-*.xml

package:
  stage: package
  script:
    - mvn package -DskipTests
  artifacts:
    paths:
      - target/*.jar

deploy-production:
  stage: deploy
  script:
    - ./deploy.sh production
  when: manual   # Continuous Delivery gate
  only:
    - main

Maven Configuration for CI/CD

A multi-module reactor (like order-service, customer-service, and shared-domain as separate modules) needs every module's version to move together. Hardcoding the version in every pom.xml means a release requires editing N files; Maven's CI Friendly Versions feature lets CI inject one version into a single placeholder instead.

<!-- pom.xml -->
<version>${revision}</version>

<properties>
    <revision>1.0.0-SNAPSHOT</revision>
</properties>

<build>
    <plugins>
        <!-- Resolves ${revision} to a real value before the artifact is
             installed/deployed — downstream consumers never see the placeholder -->
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>flatten-maven-plugin</artifactId>
            <version>1.5.0</version>
            <executions>
                <execution><goals><goal>flatten</goal></goals></execution>
            </executions>
        </plugin>
    </plugins>
</build>

# CI sets the real version at build time — every module gets it consistently
mvn -B -Drevision=1.4.0 clean package

Docker in CI/CD

Multi-stage Dockerfile

FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn -B package -DskipTests

FROM eclipse-temurin:21-jre-alpine
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar

# Non-root user — never run the JVM as root inside the container
RUN addgroup -S spring && adduser -S spring -G spring
USER spring

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Docker Compose for integration tests

services:
  order-service:
    build: .
    environment:
      - SPRING_PROFILES_ACTIVE=test
      - SPRING_DATASOURCE_URL=jdbc:postgresql://db:5432/orders_test
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    environment:
      - POSTGRES_DB=orders_test
      - POSTGRES_USER=test
      - POSTGRES_PASSWORD=test

Database Migrations in the Pipeline — the Part That Actually Breaks Production

Rolling and canary deployments (Section 9) mean two versions of your code run against the same database at the same time, for minutes or longer. If a migration in the new version isn't compatible with the old version's queries, the old instances start failing the moment the migration runs — before they're even the ones being replaced.

// V12__rename_customer_full_name.sql — Flyway migration
-- WRONG: renaming a column the old version still SELECTs by name
ALTER TABLE customers RENAME COLUMN full_name TO display_name;
-- The moment this runs, every OLD instance still executing
-- "SELECT full_name FROM customers" starts throwing SQL errors —
-- and during a rolling deploy, old instances are still serving traffic.

-- CORRECT: expand/contract pattern — add the new column first,
-- backfill, deploy code that writes to both, THEN drop the old column
-- in a LATER migration once every instance is on the new version
ALTER TABLE customers ADD COLUMN display_name VARCHAR(255);
UPDATE customers SET display_name = full_name;
-- full_name is dropped only in a future release, after this one is fully rolled out

# Running Flyway as an explicit pipeline stage — a separate step from
# the application deploy, so a failed migration blocks the rollout
# instead of half-applying during app startup
mvn flyway:migrate -Dflyway.url=$DB_URL -Dflyway.user=$DB_USER

Deployment Strategies — and What Each One Requires From Your Code

Blue-Green

Blue (current)  ← production traffic
Green (new)     ← deploy and test the new version here first

// Switch traffic once Green is verified. Rollback = switch back to Blue.

Requires: the new version must be able to run health checks (Spring Boot Actuator's /actuator/health) before receiving any real traffic — the switch is only safe if "healthy" actually means healthy.

Canary

v1.0 (current) ← 95% of traffic
v1.1 (canary)  ← 5% of traffic, monitored, gradually increased

Requires: your metrics and error rates must be observable per version — a canary you can't measure isn't a canary, it's just an unmonitored partial rollout.

Rolling

Instance 1: v1.0 -> v1.1 (updating)
Instance 2: v1.0
Instance 3: v1.0
// One instance at a time, until all are updated

Requires: the exact backward-compatibility guarantee from Section 8 — old and new instances serve real traffic against the same schema simultaneously throughout the rollout.

GitOps — the Modern "Deploy" Step

Increasingly, the final deploy step isn't your pipeline running kubectl apply directly against a cluster. Instead, a controller running inside the cluster (ArgoCD, Flux) continuously watches a Git repository of Kubernetes manifests and reconciles the cluster to match whatever is committed there.

// What actually changes for you:
// Your CI pipeline builds the image and pushes it to a registry, then
// opens a PR (or commits directly) bumping the image tag in a manifests
// repo — it never touches the cluster itself.

// manifests-repo/order-service/deployment.yaml
image: ghcr.io/shop/order-service:1.4.0   # ← this line is what your pipeline updates

// ArgoCD notices the commit, diffs it against the live cluster state,
// and applies the change itself — with a full audit trail of every
// change as ordinary Git history.

For you as a developer, this mostly means: the artifact you build and the state of the cluster are connected entirely through Git commits, so "what's running in production right now" is always answerable by reading a file in a repo, not by asking someone with cluster access.

Security Scanning in the Pipeline

name: Security Scan

on: [push, pull_request]

permissions:
  contents: read

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4

    - name: OWASP Dependency Check
      uses: dependency-check/Dependency-Check_Action@<pinned-commit-sha> # pin to a specific release commit, not @main
      with:
        project: 'order-service'
        path: '.'
        format: 'HTML'

    - uses: actions/upload-artifact@v4
      with:
        name: dependency-check-report
        path: reports/

This scans your dependencies for known CVEs. It does not protect you from Section 3's supply-chain risk — an Action itself being malicious is a different threat than a vulnerable library, and needs the SHA-pinning discipline covered there.

Best Practices and Common Pitfalls

Interview Questions