Belajar GitOps dengan ArgoCD - CI/CD Pipeline Integration

#Pendahuluan

Di episode 17 sebelumnya kita membahas notifications & alerts — bagaimana ArgoCD memberi tahu tim lewat Slack, email, atau webhook ketika status sinkronisasi atau kesehatan berubah. Namun sampai di sini kita masih memperlakukan Git sebagai sumber yang "tiba-tiba berubah" tanpa memahami siapa yang mengubahnya. Pada episode ini kita menutup lingkaran itu: mengintegrasikan ArgoCD dengan pipeline CI/CD, sehingga dari commit kode sampai aplikasi live di cluster adalah satu alur yang dapat dilacak.

Mengapa ini penting? Dalam setup tradisional, CI dan CD sering menyatu: satu pipeline menjalankan build lalu langsung kubectl apply ke cluster. Masalahnya, pipeline itu memegang kredensial cluster, dan setiap deployment adalah keputusan yang hanya tercatat di log pipeline yang bisa hilang. GitOps menawarkan pembagian kerja yang lebih sehat: CI bertanggung jawab membangun dan menguji artefak, sementara CD — yang dipegang ArgoCD — bertanggung jawab menerapkan konfigurasi yang sudah disetujui di Git. CI boleh memegang kredensial registry, CD cukup membaca Git. Setelah episode ini, pola ini akan kalian pahami sampai level implementasi.

#Memahami Pemisahan CI dan CD

Sebelum menulis pipeline, kalian harus paham siapa melakukan apa. Model GitOps membagi alur menjadi dua domain yang berbeda kepentingannya:

Intinya: CI menghasilkan artefak, CD menerapkan artefak. ArgoCD tidak perlu tahu bagaimana image dibuat; ia hanya perlu tahu bahwa image dengan tag tertentu sudah ada di registry, lalu mewujudkannya di cluster. Pemisahan ini membuat CI bisa dijalankan ulang tanpa memengaruhi cluster, dan membuat rollback CD tidak bergantung pada pipeline.

#Membangun Pipeline CI: Build Stage

Tahap build adalah urutan langkah yang menghasilkan image. Standar industri memakai lima langkah berurutan:

1. Checkout kode — mengambil source code dari branch/commit tertentu.
2. Build dan test — install dependencies, lint, unit test, build artefak. Gagal di sini berarti alur berhenti sebelum membuang-buang waktu ke langkah berikutnya.
3. Build image container — dari artefak teruji, dibuat image dengan tag unik.
4. Push ke registry — image dikirim ke registry (ECR, GCR, GHCR, Docker Hub).
5. Security scanning — image dipindai untuk CVE sebelum diizinkan dipakai di cluster.

name: ci
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: bun install --frozen-lockfile
      - run: bun run lint && bun run test
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/org/api:${{ github.sha }}

      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: ghcr.io/org/api:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: "1"

Perhatikan pola tag image: SHA commit sebagai tag adalah cara termurah untuk membuat artefak immutable — setiap commit menghasilkan image yang tidak pernah ditimpa, sehingga kalian selalu bisa merekonstruksi versi persis yang berjalan di produksi. exit-code: "1" pada Trivy membuat pipeline gagal jika ditemukan CVE dengan severity tinggi — inilah gerbang keamanan sebelum image masuk cluster.

#Menghubungkan CI ke CD: Update Manifest di Git

Setelah image berada di registry, tugas CI belum selesai. Dalam model GitOps, langkah berikutnya adalah memperbarui manifest di Git agar ArgoCD melihat image baru. Pilihan termudah adalah Kustomize images (dari episode 8):

      - uses: azure/setup-kubectl@v4
      - uses: imranismail/setup-kustomize@v2
      - run: |
          cd manifests/overlays/staging
          kustomize edit set image ghcr.io/org/api:${{ github.sha }}
          git config user.name "ci-bot"
          git config user.email "ci@org.dev"
          git commit -am "chore(staging): bump api to ${{ github.sha }}"
          git push

Setelah git push, dua hal bisa terjadi tergantung syncPolicy pada Application:

Jika Application memakai automated sync, tidak ada lagi langkah manual — ArgoCD melihat perubahan Git, menyinkronkan, dan health check berjalan. Jika manual, tim menjalankan:

Sync manual setelah approve

argocd app get api --show-operation
argocd app sync api --strategy apply
argocd app wait api --health

#Contoh Implementasi di Platform CI Lain

Pola yang sama — build, push, update manifest, ArgoCD sync — bisa dibangun di platform mana pun. Yang membedakan hanyalah sintaks:

Kunci yang harus diingat: jangan pernah memanggil argocd app sync dari pipeline untuk "men-deploy". ArgoCD seharusnya menarik sendiri dari Git. Jika kalian memanggil sync dari pipeline, kalian kembali ke model push, dan klaim utama GitOps — semua perubahan bersumber dari Git — menjadi rusak. Biarkan ArgoCD menjadi pengemudi.

#Praktik Terbaik

1. Pisahkan CI dan CD secara nyata. Pipeline CI hanya menghasilkan artefak; deployment adalah pekerjaan ArgoCD. Jangan membangun satu pipeline raksasa yang melakukan keduanya.
2. Gunakan artefak immutable. Tag image dengan SHA commit atau versi semver yang tidak pernah ditulis ulang. Tag latest adalah musuh reproducibility.
3. Gunakan promotion pipelines. Alur dev → staging → prod diwujudkan dengan mempromosikan tag yang sama (bukan membangun ulang). Image yang diuji di staging harus persis yang dipakai di prod.
4. Otomatiskan rollback. Karena setiap versi adalah commit di Git, rollback cukup git revert atau argocd app rollback. Dokumentasikan langkah rollback di runbook.
5. Jaga kecepatan feedback. Gagalkan pipeline secepat mungkin: lint sebelum build, build sebelum scan, scan sebelum push.

#Testing Strategies

Deployment yang baik diuji sebelum dan sesudah diterapkan:

• Pre-deployment validation — jalankan di tahap CI: unit test, integration test terhadap image yang sudah di-build, dan lint manifest (kubectl kustomize atau helm template --validate) untuk menangkap YAML yang rusak sebelum masuk Git.
• Post-deployment smoke tests — jalankan lewat PostSync hook (dari episode 13). ArgoCD hanya menandai sinkronisasi sukses setelah hook selesai, sehingga smoke test yang gagal otomatis memblokir status aplikasi:

PostSync hook smoke test

apiVersion: batch/v1
kind: Job
metadata:
  name: api-smoke-test
  annotations:
    argocd.argoproj.io/hook: PostSync
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: smoke
          image: curlimages/curl:latest
          command: ["sh", "-c", "curl -sf http://api:8080/healthz"]

Jika curl gagal (misalnya kode keluar non-zero), job hook gagal, dan ArgoCD menandai sinkronisasi sebagai gagal — pemicu yang bisa menyalakan notifikasi (episode 17) dan membuka jalan otomatis rollback.

#Penutup

Episode ini menyatukan seluruh alur: CI membangun dan menguji artefak lalu memperbarui manifest di Git, dan ArgoCD sebagai CD menarik perubahan dan merekonsiliasi cluster. Kita membahas lima langkah build stage, pola kustomize edit set image sebagai jembatan CI ke CD, perbandingan sync policy, contoh di GitHub Actions, GitLab, Jenkins, dan Tekton, serta testing strategy dengan PostSync hooks.

Poin yang harus kalian bawa:

• CI menghasilkan artefak immutable; CD (ArgoCD) menerapkan konfigurasi dari Git.
• Jangan pernah memanggil sync dari pipeline — biarkan ArgoCD menarik dari Git.
• Tag image dengan SHA commit untuk reproducibility dan rollback mudah.
• Promotion pipeline memakai tag yang sama di semua environment.
• PostSync hooks memberi gerbang verifikasi setelah deployment.

Alur "cepat dan dapat dilacak" sekarang siap. Namun cepat saja tidak cukup — di produksi kalian butuh cara melepas versi baru tanpa memutus pengguna. Di episode 19 selanjutnya kita akan membahas progressive delivery dengan Argo Rollouts — canary, blue-green, analisis metrik, dan traffic splitting. Sampai jumpa di episode 19!