Learn Quarkus - CI/CD & GitOps

#Introduction

Manual deployment is the biggest source of errors in production. One missed command, one different environment, and the application breaks in front of users. CI/CD automates the entire journey from commit to production.

Episode 21 covers CI/CD pipelines for Quarkus: GitHub Actions and GitLab CI, build, test, scan, and deploy automation, GitOps integration with Argo CD or Flux, as well as canary release, blue-green deployment, and rollback strategies.

#CI/CD Pipelines for Quarkus

#GitHub Actions

A GitHub Actions workflow for a Quarkus project:

name: Build Quarkus
on:
  push:
    branches: [main]
  pull_request:
 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: '21'
      - name: Cache Maven
        uses: actions/cache@v4
        with:
          path: ~/.m2
          key: maven-${{ hashFiles('**/pom.xml') }}
      - name: Test
        run: ./mvnw -B test
      - name: Package
        run: ./mvnw -B package -DskipTests

This workflow runs tests and packaging on every commit to main or pull request. actions/setup-java@v4 installs JDK 21; the Maven cache speeds up subsequent builds.

#GitLab CI

The equivalent in GitLab CI uses a .gitlab-ci.yml with test and build stages, both running in the maven:3.9-eclipse-temurin-21 image. The key to consistency: the Java version in CI must match what developers use locally.

#Build, Test, Scan, and Deploy Automation

#The Build and Test Stages

A complete pipeline has several sequential stages:

./mvnw -B test
./mvnw -B verify -Pnative -Dquarkus.native.container-build=true
docker scan target/*-runner

Tests run verification, the native build ensures compatibility, and the image scan checks for vulnerabilities before deploying.

#Image Scanning

Container images need to be scanned for vulnerabilities. In GitHub Actions, add a step with aquasecurity/trivy-action that scans the image and blocks the pipeline if vulnerabilities above a threshold are found. Scanning is the security gate between build and deploy.

#Deploy Automation

Automate the deployment to Kubernetes after all stages pass: set the image with kubectl set image deployment/belajar-quarkus belajar-quarkus=quay.io/example/belajar-quarkus:<sha-commit> then monitor with kubectl rollout status. Images are tagged with the commit SHA so every deployment can be traced back to a specific source code.

#GitOps Integration with Argo CD or Flux

#The GitOps Concept

GitOps makes the Git repository the source of truth for infrastructure. Argo CD or Flux continuously compares the state in Git with the state in the cluster, then syncs any differences.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: belajar-quarkus
  namespace: argocd
spec:
  destination:
    namespace: production
    server: https://kubernetes.default.svc
  source:
    repoURL: https://github.com/example/infra
    path: apps/belajar-quarkus
    targetRevision: main
  syncPolicy:
    automated:
      selfHeal: true

With selfHeal: true, Argo CD returns the cluster to the Git state if anything is changed manually. Deploying is no longer "running a command" but "changing Git and waiting for the sync".

#Flux

Flux offers a similar approach with Kustomization: declaring an interval, the path to the manifests, and a sourceRef to the Git repository. Both Argo CD and Flux give you a complete audit trail: every environment change is recorded as a Git commit.

#Canary Release, Blue-Green Deployment, and Rollback

#Blue-Green Deployment

Two identical environments (blue = old, green = new). Traffic is fully switched after green passes verification:

kubectl apply -f deploy/green/deployment.yml
kubectl rollout status deployment/belajar-quarkus-green
kubectl patch svc belajar-quarkus -p '{"spec":{"selector":{"version":"green"}}}'

If something goes wrong, switch back to blue in seconds — an instant rollback without redeploying. Monitor the progress with kubectl rollout status deployment/belajar-quarkus-green.

#Canary Release

Traffic is split gradually: 5% to the new version, then 25%, 50%, and so on. A service mesh (episode 14) or a tool like Argo Rollouts makes this easy by declaring steps such as setWeight and pause for a given duration. Canary minimizes risk: problems are detected on a small fraction of traffic before all users are affected.

#Rollback

With GitOps, rollback is simple: revert the Git commit. With image tags, rollback is setting the image to the previous version. Always prepare a rollback runbook before a release — and test the process.

#Wrap-Up

Episode 21 automates your application's journey to production: understanding Quarkus CI/CD pipelines in GitHub Actions and GitLab CI, build, test, scan, and deploy automation, GitOps integration with Argo CD and Flux, as well as canary, blue-green, and rollback strategies.

Key takeaways:

• CI/CD automates test, build, scan, and deploy.
• The JDK in CI must match the developers' local version.
• Image scanning with Trivy is a security gate before deploy.
• GitOps makes Git the source of truth for infrastructure.
• Blue-green deployment gives instant rollback.
• Canary release splits traffic gradually to reduce risk.
• Rollback must be tested, not just planned.

In episode 22 we'll cover observability and production support — distributed tracing with OpenTelemetry, centralized logging and correlation IDs, production-ready metrics, health, and alerting, as well as incident response, error tracing, and service troubleshooting.