Belajar Spring Boot - CI/CD & Release Automation

#Pendahuluan

Kode yang hanya hidup di repository belum berharga — ia berharga saat sampai ke pengguna dengan cara yang aman dan cepat. Episode 21 membahas CI/CD dan release automation untuk aplikasi Spring Boot.

Kalian akan membangun pipeline dengan GitHub Actions dan GitLab CI, mengotomasi build, test, dan security scan, mengelola artefak dan versioning, lalu menerapkan strategi deploy yang berisiko rendah seperti canary, blue-green, dan rollback.

#Pipeline CI/CD dengan GitHub Actions

#Struktur Pipeline

GitHub Actions menjalankan job berdasarkan event. Pipeline khas Spring Boot terdiri dari: checkout, setup JDK, build dan test, lalu deploy. Contoh 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

Cache Maven mempercepat eksekusi dengan memakai dependency yang sudah diunduh. Job build ini menjadi gerbang: jika test gagal, tidak ada deploy.

#Pipeline Deploy

Job deploy berjalan hanya di branch utama setelah build sukses:

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

Secret seperti REGISTRY_PASSWORD diambil dari GitHub Secrets — jangan pernah menaruh credential langsung di workflow.

#Build, Test, Security Scan, dan Deploy Otomatis

#Otomasi yang Lengkap

Pipeline produksi yang baik menggabungkan beberapa tahap:

1. Build — compile dan buat artefak.
2. Test — unit, integration, dan contract test.
3. Security scan — memeriksa dependency yang rentan.
4. Package — buat image container.
5. Deploy — kirim image ke environment target.

#Security Scan Dependency

Analisis dependency rentan bisa dijalankan otomatis. Untuk Maven, plugin OWASP Dependency-Check bisa diintegrasikan:

<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>

Plugin ini memeriksa setiap dependency terhadap database kerentanan publik (CVE) dan menggagalkan build jika ditemukan celah berbahaya. Gabungkan dengan ghcr.io/anchore/scan-action atau trivy untuk memindai image container setelah dibangun.

#Artifact Registry dan Versioning

#Menyimpan Artefak dengan Benar

Artefak build — jar atau image — disimpan di artifact registry yang terpusat: GitHub Container Registry, Docker Hub, AWS ECR, atau Artifactory. Setiap artefak diberi tag yang tidak ambigu:

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

Tag versi semantik (1.2.3) menandai rilis, sedangkan tag sha-... menandai setiap build — kombinasi keduanya memungkinkan rollback ke build tertentu.

#Versioning Semantik

Terapkan semantic versioning: MAJOR.MINOR.PATCH. Versi otomatis bisa dihasilkan dari commit message (misalnya dengan semantic-release atau GitVersion) sehingga setiap perubahan yang digabung menghasilkan versi baru tanpa campur tangan manual.

#Strategi Deployment

#Blue-Green Deployment

Blue-green mempertahankan dua environment: blue (versi lama) dan green (versi baru). Setelah green siap dan lulus readiness probe, traffic dialihkan:

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

Perintah kubectl patch service belajar -p '{"spec":{"selector":{"version":"green"}}}' mengalihkan service ke pod green. Rollback semudah mengembalikan selector ke blue — versi lama tetap berjalan.

#Canary Release

Canary mengirim sebagian kecil traffic ke versi baru — misalnya 10% — sambil memantau metrik error dan latency. Jika sehat, porsi dinaikkan bertahap hingga 100%. Kubernetes Service Mesh seperti Istio atau Argo Rollouts menangani alokasi traffic ini secara otomatis.

#Rollback Strategy

Setiap deploy harus punya jalur mundur. Strategi yang solid:

• Simpan artefak versi lama di registry — jangan menimpa.
• Monitor metrik segera setelah deploy untuk mendeteksi regresi.
• Otomasi rollback saat threshold error terlampaui.

Rollback bukan pengganti pengujian yang baik — ia adalah jaring pengaman terakhir.

#Penutup

Episode 21 membekali kalian dengan otomasi rilis: pipeline CI/CD dengan GitHub Actions dan GitLab CI, integrasi build, test, security scan, dan deploy otomatis, pengelolaan artefak dengan versioning, serta strategi canary, blue-green, dan rollback.

Inti yang harus dibawa pulang:

• Pipeline CI terdiri dari build, test, security scan, dan deploy.
• GitHub Actions memakai needs dan if untuk mengatur urutan job.
• Dependency-Check dan Trivy memindai dependency serta image dari kerentanan.
• Simpan artefak di registry dengan tag versi dan tag sha.
• Blue-green mengalihkan traffic antara dua environment yang selalu siap.
• Canary melepas traffic bertahap; rollback adalah jaring pengaman wajib.

Di episode 22 selanjutnya kita akan membahas observability dan production support — distributed tracing dengan OpenTelemetry, centralized logging dan structured log correlation, monitoring health dan metrics, serta incident management dengan readiness dan liveness.