Learn Spring Boot - CI/CD & Release Automation

#Introduction

Code that only lives in a repository isn't valuable — it becomes valuable when it reaches users safely and quickly. Episode 21 covers CI/CD and release automation for Spring Boot applications.

You'll build pipelines with GitHub Actions and GitLab CI, automate build, test, and security scans, manage artifacts and versioning, and apply low-risk deployment strategies like canary, blue-green, and rollback.

#CI/CD Pipelines with GitHub Actions

#Pipeline Structure

GitHub Actions runs jobs based on events. A typical Spring Boot pipeline consists of: checkout, JDK setup, build and test, then deploy. An example workflow:

name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "21"
          cache: maven
      - name: Build dan test
        run: ./mvnw clean verify

Maven caching speeds up execution by reusing already-downloaded dependencies. This build job is the gate: if tests fail, there's no deploy.

#Deploy Pipelines

The deploy job runs only on the main branch after a successful build:

deploy:
  runs-on: ubuntu-latest
  needs: build
  if: github.ref == 'refs/heads/main'
  steps:
    - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "21"
      - name: Build image dan push
        run: ./mvnw spring-boot:build-image
      - env:
          REGISTRY_PASSWORD: ${{ secrets.REGISTRY_PASSWORD }}
        run: docker push registry.example.com/belajar:latest

Secrets like REGISTRY_PASSWORD are taken from GitHub Secrets — never put credentials directly in a workflow.

#Automated Build, Test, Security Scan, and Deploy

#Complete Automation

A good production pipeline combines several stages:

1. Build — compile and create artifacts.
2. Test — unit, integration, and contract tests.
3. Security scan — check for vulnerable dependencies.
4. Package — create the container image.
5. Deploy — push the image to the target environment.

#Dependency Security Scanning

Vulnerable dependency analysis can run automatically. For Maven, the OWASP Dependency-Check plugin can be integrated:

<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>9.2.0</version>
    <executions>
        <execution>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

This plugin checks every dependency against the public vulnerability (CVE) database and fails the build if dangerous vulnerabilities are found. Combine it with ghcr.io/anchore/scan-action or trivy to scan the container image after it's built.

#Artifact Registries and Versioning

#Storing Artifacts Correctly

Build artifacts — jars or images — are stored in a centralized artifact registry: GitHub Container Registry, Docker Hub, AWS ECR, or Artifactory. Every artifact gets an unambiguous tag:

docker tag belajar:latest registry.example.com/belajar:1.2.3
docker tag belajar:latest registry.example.com/belajar:sha-abc123

A semantic version tag (1.2.3) marks a release, while a sha-... tag marks each build — combining both lets you roll back to a specific build.

#Semantic Versioning

Apply semantic versioning: MAJOR.MINOR.PATCH. Versions can be generated automatically from commit messages (for example with semantic-release or GitVersion), so every merged change produces a new version without manual intervention.

#Deployment Strategies

#Blue-Green Deployment

Blue-green keeps two environments: blue (old version) and green (new version). Once green is ready and passes its readiness probe, traffic is switched:

kubectl rollout status deployment/belajar-green
kubectl patch service belajar -p '{"spec":{"selector":{"version":"green"}}}'

The command kubectl patch service belajar -p '{"spec":{"selector":{"version":"green"}}}' points the service at the green pods. Rollback is as easy as switching the selector back to blue — the old version keeps running.

#Canary Release

Canary sends a small fraction of traffic to the new version — say 10% — while monitoring error and latency metrics. If it's healthy, the share is increased gradually to 100%. A Kubernetes service mesh like Istio or Argo Rollouts handles this traffic allocation automatically.

#Rollback Strategy

Every deploy needs a path back. A solid strategy:

• Keep old version artifacts in the registry — don't overwrite them.
• Monitor metrics right after deploy to catch regressions.
• Automate rollback when the error threshold is exceeded.

Rollback isn't a substitute for good testing — it's the last safety net.

#Closing

Episode 21 equipped you with release automation: CI/CD pipelines with GitHub Actions and GitLab CI, integrated build, test, security scan, and automated deploy, artifact management with versioning, and canary, blue-green, and rollback strategies.

Key takeaways:

• A CI pipeline consists of build, test, security scan, and deploy.
• GitHub Actions uses needs and if to order jobs.
• Dependency-Check and Trivy scan dependencies and images for vulnerabilities.
• Store artifacts in a registry with version and sha tags.
• Blue-green switches traffic between two always-ready environments.
• Canary releases traffic gradually; rollback is a mandatory safety net.

In the next episode, episode 22, we'll discuss observability and production support — distributed tracing with OpenTelemetry, centralized logging and structured log correlation, health and metrics monitoring, and incident management with readiness and liveness.