Belajar Semantic Release - GitOps dan Release Automation

#Pendahuluan

Di episode 18 kita memantau rilis: tag versi, dashboard release, dan validasi pasca-rilis. Tapi ada satu mata rantai yang sering terputus: versi sudah terbit otomatis, sementara deployment ke cluster masih dikerjakan manual oleh manusia. Di sinilah GitOps masuk. Prinsipnya sederhana tapi kuat — Git adalah satu-satunya sumber kebenaran, dan perubahan yang masuk ke Git otomatis disinkronkan ke environment oleh operator seperti ArgoCD atau Flux.

Di episode ini kita membahas:

1. Konsep GitOps dan posisi release automation di dalamnya.
2. Branch-based environment promotion dari staging ke produksi.
3. Dua pola sinkronisasi: manifest repo plus auto-sync, dan image updater.
4. Memicu workflow deploy dari tag release.

#Pembahasan Utama

#Konsep GitOps: Git sebagai Satu-satunya Sumber Kebenaran

GitOps, pola yang dipopulerkan Weaveworks dan diadopsi ArgoCD maupun Flux, berdiri di atas tiga prinsip inti:

1. Desired state dideklarasikan di Git. Konfigurasi aplikasi, image tag, dan jumlah replica ditulis sebagai manifest — bukan hasil klik-klik di dashboard.
2. Operator menyinkronkan. ArgoCD atau Flux membandingkan state di Git dengan state di cluster, lalu menyesuaikan hingga keduanya cocok.
3. Semua perubahan lewat Git. Tidak ada yang bisa mengubah produksi di luar Git — audit trail otomatis, bukan janji.

Semantic-release adalah pasangan alami GitOps. Release automation menentukan versi, GitOps menentukan ke mana versi itu berjalan. Keduanya bekerja dari sumber yang sama: Git.

#Menyelaraskan Release dengan Deployment

Alur lengkapnya menjadi satu garis lurus tanpa intervensi manusia:

1. Developer merge PR ke staging.
2. CI membangun image dan menandainya dengan versi release candidate.
3. semantic-release menerbitkan tag v1.4.0-rc.1 di branch staging.
4. GitOps menyinkronkan image versi itu ke environment staging.
5. Setelah lolos uji, branch staging di-merge ke main.
6. semantic-release menerbitkan tag v1.4.0, lalu deployment ke produksi berjalan.

Kuncinya satu: versi yang dirilis semantic-release harus identik dengan versi image yang di-deploy. Jangan biarkan deploy mengambil versi sendiri yang berbeda dari tag rilis. Image ditandai persis seperti tag versi:

docker build -t ghcr.io/acme/api:"${RELEASE_VERSION}" .
docker push ghcr.io/acme/api:"${RELEASE_VERSION}"

Variabel RELEASE_VERSION diambil langsung dari output semantic-release, bukan ditebak. Dengan begitu kalian selalu bisa menelusuri "versi X berjalan di cluster" kembali ke commit dan changelog yang tepat.

#Branch-based Environment Promotion

Model yang paling mudah dipahami: satu branch untuk satu environment.

Promotion bukan berarti menyalin artifact, melainkan mempromosikan versi yang sudah terverifikasi. Kode di staging sudah diuji, sehingga merge staging ke main hanya mewarisi versi yang sudah dikenal baik. semantic-release mengurus kenaikan versinya:

• Commit fix baru di staging → 1.4.0-rc.2.
• Setelah merge ke main → 1.4.0 stabil tanpa suffix.
• Commit feat berikutnya di staging → 1.5.0-rc.1.

#Pola 1: Manifest Repo + Auto-sync

Pola paling populer untuk ArgoCD: aplikasi target diatur lewat sebuah repository manifest (misalnya acme/deploy-configs) yang berisi kustomize atau helm chart. Workflow release menulis versi baru ke manifest itu, lalu ArgoCD menyinkronkannya ke cluster.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api
  namespace: argocd
spec:
  project: default
  destination:
    namespace: production
    server: https://kubernetes.default.svc
  source:
    repoURL: https://github.com/acme/deploy-configs
    targetRevision: production
    path: apps/api
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Workflow release mengganti image tag di manifest lalu push ke repository tersebut:

#!/usr/bin/env bash
set -euo pipefail
 
VERSION="${1:?tag versi wajib diisi}"
MANIFEST_REPO="git@github.com:acme/deploy-configs.git"
 
git clone --depth 1 --branch production "$MANIFEST_REPO" /tmp/deploy
cd /tmp/deploy
sed -i "s|image: ghcr.io/acme/api:.*|image: ghcr.io/acme/api:${VERSION}|" apps/api/deploy.yaml
git add apps/api/deploy.yaml
git commit -m "chore: promote api ${VERSION} ke production"
git push

Kelebihan pola ini: setiap perubahan deployment adalah sebuah commit yang bisa direview dan di-revert. Rollback tinggal git revert v1.3.0 ke versi sebelumnya — dan ArgoCD otomatis mengembalikan cluster ke kondisi itu.

#Pola 2: Image Updater yang Memantau Registry

Pola kedua tidak membutuhkan workflow tambahan sama sekali. ArgoCD Image Updater atau Flux ImagePolicy memantau registry container, menemukan tag versi baru yang memenuhi aturan semver, lalu memperbarui manifest secara otomatis.

apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
  name: api
spec:
  imageRepositoryRef:
    name: api
  filterTags:
    pattern: '^v(?P<semver>\d+\.\d+\.\d+)$'
  policy:
    semver:
      range: '>=1.0.0'

Policy di atas hanya mengambil tag versi stabil tanpa suffix rc, sehingga image updater tidak akan pernah men-deploy release candidate ke produksi. Kalian bisa memverifikasi kebijakan yang aktif dengan flux get imagepolicy api.

#Memicu Workflow Deploy dari Release

Bagaimana deployment tahu bahwa sebuah release baru saja diterbitkan? Dua trigger yang paling umum:

1. Event release — berjalan ketika GitHub Release diterbitkan oleh semantic-release.
2. Trigger workflow_run — berjalan ketika workflow release lain selesai dengan sukses.

Contoh trigger berbasis event release:

name: Deploy Production
 
on:
  release:
    types: [published]
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout manifest repo
        uses: actions/checkout@v4
        with:
          repository: acme/deploy-configs
 
      - name: Promote ke production
        run: ./promote.sh "${{ github.event.release.tag_name }}"

Contoh trigger berbasis workflow lain yang selesai:

name: Deploy Staging
 
on:
  workflow_run:
    workflows: ["Release Candidate"]
    types: [completed]
    branches: [staging]
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Ambil versi dari release terakhir
        run: |
          VERSION="${{ github.event.workflow_run.head_branch }}"
          echo "men-deploy hasil release di branch $VERSION"

#Penutup

Di episode ini kita menghubungkan release automation dengan deployment automation:

• GitOps menjadikan Git satu-satunya sumber kebenaran, dan semantic-release menyediakan versi yang bisa ditelusuri.
• Promotion dari staging ke produksi terjadi lewat branch: staging untuk rc, main untuk stable.
• ArgoCD dan Flux menyinkronkan perubahan lewat manifest repo atau image updater.
• Trigger deploy menggunakan event release atau workflow_run — satu trigger, jangan dua.

Release dan deployment kini berada dalam satu alur otomatis. Di episode 20 kita memastikan seluruh tim bisa mengikuti standar ini — lewat dokumentasi, onboarding, dan code review. Sampai jumpa!