Belajar GitOps dengan ArgoCD - GitOps Workflow & Branch Strategies

#Pendahuluan

Di episode 14 sebelumnya kita mengatur kapan sync boleh terjadi dengan Sync Windows. Kini semua komponen teknis sudah lengkap — Application, Project, ApplicationSet, Secret, Hooks, dan Window. Tapi ada satu lapisan yang sering dilupakan dan justru menentukan sukses tim: alur kerja manusia di sekitar Git. Bagaimana perubahan mengalir dari laptop developer menuju cluster production? Di episode ini kita membahas GitOps Workflow & Branch Strategies — pola repository, branch, dan promosi yang membuat Git benar-benar menjadi sumber kebenaran yang terorganisir.

Mengapa ini penting? ArgoCD hanya melakukan apa yang ada di Git. Jika struktur Git-nya semrawut, hasilnya adalah deployment yang semrawut. Sebaliknya, repository GitOps yang tertata rapi adalah bagian dari mekanisme kontrol: setiap perubahan terview, terdokumentasi, dan mudah di-rollback — persis yang dibutuhkan untuk audit dan operasional berskala.

#Git Workflow Patterns

Ada tiga pola besar yang menentukan cara tim menulis perubahan:

#Trunk-Based Development

Semua developer bekerja pada satu branch utama (biasanya main), dengan fitur dikembangkan dalam short-lived branch yang di-merge cepat melalui PR. Keunggulannya: integrasi terus-menerus, konflik minimal, dan riwayat linier. Ini pola yang paling cocok untuk GitOps karena ArgoCD menyinkronkan satu targetRevision yang jelas.

#GitFlow

Menggunakan branch develop sebagai pusat pengembangan dan branch feature/* + release/* + hotfix/* di sekitarnya. Lebih terstruktur untuk rilis besar, tapi lebih berat: perubahan harus melewati beberapa level branch, dan ini kerap membuat konfigurasi GitOps menjadi duplikatif.

#Environment Branches & Release Branches

Pola perantara: satu branch per environment (dev, staging, prod). ArgoCD di environment dev menyinkronkan branch dev, dan seterusnya. Promosi dilakukan dengan merge antar branch. Release branch (release-1.2) dipakai untuk mengunci versi yang akan dirilis — cocok dikombinasikan dengan tag.

#Struktur Direktori Repository

Selain branch, struktur direktori menentukan skala repository GitOps. Tiga pendekatan umum:

#Environment-Based

gitops-repo/
├── apps/
│   ├── billing/
│   │   ├── base/
│   │   ├── overlays/
│   │   │   ├── dev/
│   │   │   ├── staging/
│   │   │   └── prod/
│   └── orders/
└── clusters/
    ├── dev/
    └── prod/

Setiap aplikasi punya base (default) dan overlays per environment. Promosi = menambahkan atau mengubah overlay. Ini pola paling umum dan mudah dipahami.

#Application-Based & Cluster-Based

• Application-based — satu direktori per aplikasi berisi semua manifest miliknya, sering dikombinasikan dengan monorepo aplikasi.
• Cluster-based — satu direktori per cluster berisi seluruh manifest untuk cluster itu, cocok untuk multi-cluster (episode 9) karena isi tiap cluster tampil eksplisit.
• Hybrid — menggabungkan keduanya: per cluster, lalu per aplikasi di dalamnya.

gitops-repo/
├── clusters/
│   ├── eks-prod/
│   │   ├── namespace-billing/
│   │   ├── namespace-orders/
│   │   └── platform/
│   └── kind-staging/
│       ├── namespace-billing/
│       └── namespace-orders/
└── apps/
    └── shared-charts/

#Strategi Promosi

Promosi adalah proses memindahkan perubahan dari environment rendah ke tinggi. Empat strategi:

Pola yang sangat direkomendasikan untuk production adalah tag-based + PR promotion: tim mempromosikan dengan membuat PR yang mengubah versi image di overlay prod ke tag tertentu, dan ArgoCD hanya menerapkan jika PR disetujui.

Overlay prod menunjuk tag

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
images:
  - name: ghcr.io/devnull/billing-api
    newTag: v1.2.3

#Change Management

Bagian ini yang membuat GitOps unggul dalam tata kelola:

• PR reviews — setiap perubahan ke repository GitOps wajib lewat PR dengan reviewer yang memahami environment tujuannya. Protections branch (required reviews) membuatnya sulit dilewati.
• Approvals — untuk production, beri CODEOWNERS khusus (misal tim platform) dan wajibkan persetujuan — bisa diperkuat dengan status checks dari CI.
• Change tracking — karena semua perubahan adalah commit, tiap deployment bisa dilacak balik ke PR dan issue terkait. Gunakan conventional commits (sesuai AGENTS.md) agar changelog ter-generasi otomatis.
• Rollback procedures — rollback dalam GitOps adalah revert commit (atau argocd app rollback untuk state sebelumnya). Karena manifest versioned, memutar balik selalu mungkin dan terdokumentasi.

#Kesalahan Umum (Common Pitfalls)

1. Membuat banyak branch environment yang menyimpang. Branch prod yang di-merge manual tanpa alur promosi jelas akan cepat berbeda dari staging. Standarisasi alur promosi.
2. Manifest diedit langsung di cluster. Ini melanggar prinsip GitOps dan menciptakan drift; ArgoCD akan mengembalikannya ke state Git.
3. Rollback dengan menulis ulang history. Jangan git push --force untuk "menghilangkan" perubahan; gunakan revert sehingga jejak audit tetap utuh.
4. Struktur direktori berubah-ubah. Ganti-ganti layout setiap bulan membuat Application dan ApplicationSet tidak konsisten. Putuskan sekali, dokumentasikan.
5. Version image tanpa tag bermakna. latest sulit di-rollback dan tidak reproducible. Wajibkan semver (kita dalami di episode 16).

#Penutup

Episode ini merangkum sisi manusia dari GitOps: perbandingan trunk-based, GitFlow, dan environment branches, struktur direktori environment-based/application-based/cluster-based, strategi promosi branch/tag/PR/overlay, dan change management lewat PR review, approval, change tracking, serta prosedur rollback.

Poin yang harus kalian bawa:

• Repository GitOps yang rapi adalah mekanisme kontrol, bukan sekadar tempat menyimpan file.
• Trunk-based + tag-based promotion adalah kombinasi paling modern dan aman.
• Pisahkan repo aplikasi dan repo GitOps untuk permission yang berbeda.
• Setiap perubahan production wajib lewat PR dan review.
• Rollback = revert commit; jangan menulis ulang history.

Menjaga versi image tetap sinkron antar environment secara manual sangat melelahkan. Di episode 16 selanjutnya kita membahas Image Updater - Automated Image Updates: instalasi ArgoCD Image Updater, strategi semver/latest/digest, write-back ke Git, dan pola dev otomatis hingga approval manual di produksi. Sampai jumpa di episode 16!