Belajar GitOps dengan ArgoCD - Enterprise Patterns & Best Practices

#Pendahuluan

Di episode 31 sebelumnya kita membawa pola GitOps ke tiga cloud dan kombinasi multi-cloud. Namun jika kalian perhatikan, semua episode sejauh ini membahas teknologi. Di dunia nyata, kegagalan adopsi GitOps hampir tidak pernah disebabkan oleh teknologi — melainkan oleh struktur tim, strategi repo, proses approval, dan dokumentasi yang tidak ikut berubah. GitOps yang hebat di atas kertas bisa mati di tengah jalan karena platform team menjadi bottleneck atau karena tidak ada runbook saat insiden.

Episode ini adalah bagian organisasi dan proses. Kita membahas pola enterprise: bagaimana platform team bekerja, bagaimana repo disusun, bagaimana environment dikelola, bagaimana perubahan disetujui, dan bagaimana dokumentasi dirawat.

#Struktur Organisasi

#Platform Team dan Otonomi Tim Aplikasi

Model yang paling berhasil memiliki dua peran yang jelas:

Tujuan platform team adalah menghilangkan dirinya dari jalur kritis untuk perubahan rutin. Tim aplikasi men-deploy sendiri lewat self-service (episode 28); platform team hanya turun tangan untuk perubahan platform, insiden, dan governance. Jika tim aplikasi harus menunggu platform team untuk deploy, GitOps belum berhasil.

#Model Governance

Tiga model governance yang umum:

1. Centralized — semua perubahan lewat platform team; paling aman, paling lambat, cocok untuk awal.
2. Federated — platform team menetapkan standar dan template; tim aplikasi bebas dalam batas itu. Model yang paling seimbang.
3. Autonomous — tim aplikasi sepenuhnya mengelola stack mereka; cepat, tetapi butuh kedisiplinan tinggi dan tool yang mencegah kesalahan.

#Center of Excellence (CoE)

CoE adalah tim kecil (2-4 orang) yang bukan pemilik platform penuh, melainkan penjaga standar: menyusun template, golden path, pola yang disepakati, dan menjawab pertanyaan tim lain. CoE mencegah fragmentasi — lima tim membuat lima pola ArgoCD yang berbeda. Dokumentasi CoE juga menjadi jalur karier: anggotanya silih berganti sehingga pengetahuan menyebar.

#Strategi Repository

#Monorepo vs Polyrepo

Praktik umum: monorepo manifest per environment (satu repo berisi dev/, staging/, prod/) adalah titik awal yang paling sederhana. Berpindah ke polyrepo ketika ukuran repo membuat klon lambat atau kebutuhan isolasi akses semakin kuat.

#Shared Configuration Repository

Repo shared berisi nilai yang dipakai semua tim: versi image base, storage class, sertifikat. Di-refer lewat Kustomize base atau nilai Helm. Perubahan di sini berpengaruh ke semua orang — jadi repo ini yang paling ketat review-nya.

#Template Repositories

Template repo (episode 28) adalah golden path: struktur aplikasi yang sudah sesuai standar platform. Tim aplikasi memulai dari template ini, bukan dari nol. Template dikelola CoE dan menjadi mekanisme penyebaran best practice secara otomatis.

#Version Control Strategy

• Branch protection — repo manifest production harus memakai branch protection: wajib review, tanpa push langsung.
• Tagged releases — untuk production, promo via tag (episode 15) memberi jejak yang jelas: release-1.2.3 berarti sekumpulan manifest yang konsisten.
• Signed commits — untuk lingkungan yang diaudit, tanda tangan commit memberi bukti non-repudiasi.

#Manajemen Environment

#Environment Parity

Environment dev, staging, dan prod harus sedekat mungkin — bedanya hanya nilai (ukuran, traffic, quota), bukan perilaku. Parity membuat pengujian di staging benar-benar bermakna. GitOps membantu: manifest yang sama dipromosikan ke atas, bukan ditulis ulang per environment.

#Configuration Management

Pisahkan manifest dan konfigurasi: manifest identik lintas environment, konfigurasi (nilai) berbeda per environment. Di Helm: satu values.yaml per environment; di Kustomize: satu overlay per environment (episode 8).

#Promotion Pipelines

Promotion = memindahkan manifest dari satu environment ke environment berikutnya, biasanya lewat:

git tag -a release-1.2.3 -m "promote api 1.2.3"
git push origin release-1.2.3
argocd app set api-staging --revision release-1.2.3

Setelah staging terbukti sehat (health + smoke test di episode 13), hal yang sama dilakukan untuk prod. Catat: yang dipromosikan adalah manifest, bukan hasil deploy — deployment di cluster adalah turunan, bukan artefak yang dipindah tangan.

#Environment-Specific Overrides

Override per environment dijaga tetap sedikit dan eksplisit: replicaCount, resources, ingress host, storageClass. Setiap override adalah tempat potensi drift — semakin sedikit, semakin aman.

#Change Management

#Approval Workflows

Git adalah mekanisme approval terbaik: PR + review = approval workflow. Semakin tinggi environment, semakin ketat jumlah reviewer:

branch-protection:
  - branch: prod
    required_pull_request_reviews:
      required_approving_review_count: 2
    required_status_checks:
      - argocd-health

#Change Advisory Board (CAB) dan Prosedur Darurat

Untuk perubahan besar, pertahankan CAB (Change Advisory Board) — tetapi batasi cakupannya pada perubahan berisiko tinggi (migrasi platform, perubahan infra), bukan setiap bump image. Emergency procedure untuk insiden produksi harus lebih cepat dari proses normal: mekanisme hotfix dengan akses khusus, misalnya token sementara yang valid selama 60 menit, atau override sync window (episode 14). Proses darurat yang lambat justru mendorong orang memotong jalur — yang lebih berbahaya.

#Rollback Policies

Karena Git adalah kebenaran, rollback = argocd app rollback api <revision> atau revert commit. Kebijakannya harus ditulis, bukan tersirat: kapan rollback dilakukan (misalnya error rate > 5 persen selama 5 menit), siapa yang boleh, dan bagaimana reporting-nya. Rollback bukan penyelesaian masalah — ia mengembalikan ke kondisi terakhir yang diketahui baik, lalu insiden didokumentasikan.

#Dokumentasi

Dokumentasi adalah infrastruktur yang jarang di-deploy tetapi selalu dipakai saat panik. Empat dokumen yang wajib ada:

• Runbooks — prosedur langkah-demi-langkah untuk skenario umum: ArgoCD down, sync failure, DR failover. Runbook menuntun operator yang mungkin baru on-call pertama kali.
• Architecture diagrams — peta ArgoCD, cluster, repo, dan alur data. Diagram as-code (misalnya Mermaid di repo) lebih mudah dirawat daripada gambar statis.
• Onboarding guides — cara tim baru memakai platform: membuat aplikasi, memakai template, melewati approval.
• Troubleshooting guides — episode 27 dijadikan runbook: gejala → kemungkinan penyebab → perintah.

Simpan semua di repo (misalnya di bawah docs/) sehingga dokumentasi ikut versi bersama kode dan bisa di-review lewat PR.

#Penutup

Episode ini menyusun sisi organisasi: struktur platform team dengan otonomi tim aplikasi, model governance dari centralized hingga autonomous, strategi repo monorepo vs polyrepo dengan shared config dan template repo, manajemen environment dengan parity dan promotion pipeline, change management dengan approval, CAB, dan jalur darurat, serta dokumentasi runbook, diagram, onboarding, dan troubleshooting.

Poin yang harus kalian bawa:

• Platform team sukses jika berhasil menghilangkan diri dari jalur kritis.
• Git sebagai mekanisme approval (PR + review) mengalahkan tool approval terpisah.
• Yang dipromosikan adalah manifest, bukan hasil deploy.
• Jalur darurat resmi yang cepat lebih aman daripada proses normal yang lambat.
• Dokumentasi adalah infrastruktur — rawat seperti kode.

Organisasi sudah siap. Sekarang mari kita bicara tentang hal yang selalu ditanyakan manajemen. Di episode 33 selanjutnya kita membahas cost optimization — right-sizing resource, optimasi cluster dengan spot instance dan autoscaling, efisiensi GitOps, serta monitoring biaya dengan cost allocation dan deteksi anomali. Sampai jumpa di episode 33!