Belajar GitOps - FluxCD - Enterprise Adoption Patterns

#Pendahuluan

Di episode 30 kalian sudah menerapkan FluxCD di cloud provider yang berbeda. Teknisnya sudah kuat, tetapi mengadopsi FluxCD di organisasi besar bukan persoalan perintah — melainkan persoalan manusia, proses, dan struktur. Di episode 31 ini kalian belajar pola adopsi enterprise: bagaimana membangun platform engineering, membagi tanggung jawab antara tim platform dan tim aplikasi, memilih strategi repositori, mengelola perubahan, dan membawa pengembang baru ke dalam alur GitOps.

Tujuan akhirnya sederhana: GitOps harus menjadi jalur jalan raya, bukan jalan tol yang hanya bisa dipakai segelintir orang.

#Platform Engineering

#Internal Developer Platform

Di banyak enterprise, FluxCD adalah komponen dari Internal Developer Platform (IDP) — satu lapisan yang menyembunyikan kompleksitas Kubernetes di balik antarmuka yang ramah pengembang. IDP menyatukan FluxCD, manajemen secret, ingress, observability, dan template aplikasi ke dalam satu pengalaman self-service.

#Self-Service Workflows

Pola paling umum: pengembang tidak pernah memegang kubectl atau folder di repositori fleet secara langsung. Sebagai gantinya mereka mengajukan perubahan melalui mekanisme yang lebih tinggi — sebuah PR, sebuah form, atau sebuah scaffolding tool. Platform menerima permintaan, memvalidasi, lalu meng-generate kandidat konfigurasi.

#Template Repositories dan Golden Paths

Golden path adalah jalur yang sudah teruji dan didukung penuh oleh platform. Untuk FluxCD, golden path berarti template repositori aplikasi yang sudah berisi:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: myapp
  namespace: apps
spec:
  interval: 5m
  path: ./apps/myapp
  prune: true
  sourceRef:
    kind: GitRepository
    name: myapp
  postBuild:
    substitute:
      image: ghcr.io/devvnull/myapp:1.2.0

Pengembang cukup mengisi nilai pada postBuild.substitute, dan Flux yang menyelesaikan sisanya.

#Struktur Organisasi

#Tanggung Jawab Tim Platform

Tim platform mengelola fondasi: repositori fleet, controller Flux, kebijakan secret, upgrade cluster, dan hal-hal lintas tim. Mereka menetapkan standar — bukan mengeksekusi deployment aplikasi.

#Otonomi Tim Aplikasi

Tim aplikasi bertanggung jawab penuh atas deployment-nya sendiri. Mereka mengubah Deployment, Service, dan HorizontalPodAutoscaler aplikasi mereka melalui PR ke repositori aplikasi, sementara Flux yang berada di sisi cluster menariknya.

#Shared Services dan Governance

Layanan bersama seperti ingress controller, monitoring, dan policy engine dikelola tim platform sebagai shared services. Governance dijalankan lewat mekanisme Git yang sama: codeowners, branch protection, dan policy as code — bukan lewat lisan.

# file CODEOWNERS di repositori fleet
/clusters/prod  @platform-leads
/apps/          @platform-leads @squad-web
/.github/       @platform-leads

#Strategi Repositori

Keputusan berikutnya adalah di mana kode tinggal. Ada tiga pola utama:

• Monorepo — semua aplikasi dan infrastruktur dalam satu repositori. Kelebihan: satu titik masuk, perubahan terkoordinasi, mudah direview. Kekurangan: ukuran dan akses menjadi sulit dikendalikan di organisasi besar.
• Polyrepo — satu repositori per tim atau per aplikasi. Kelebihan: isolasi dan otonomi jelas. Kekurangan: koordinasi antar repositori lebih berat, boilerplate berulang.
• Hybrid — repositori fleet terpisah untuk platform, repositori aplikasi per tim. Ini pola paling umum di enterprise yang memakai FluxCD.

Perbandingannya:

#Manajemen Perubahan

#Pull Request Workflows

Semua perubahan ke lingkungan berjalan lewat PR. CI memvalidasi YAML, memeriksa render kustomize build, dan menjalankan flux diff terhadap state cluster sebelum di-merge:

kustomize build ./clusters/prod > /tmp/prod.yaml
flux diff kustomization prod --path ./clusters/prod

#Approval, Change Advisory Board, dan Darurat

Environment staging cukup di-review oleh rekan satu tim. Production memerlukan approval tambahan — misalnya oleh tim platform atau Change Advisory Board (CAB) untuk perubahan besar. Untuk keadaan darurat, sediakan jalur hotfix yang cepat namun tetap tercatat: PR kecil yang langsung di-merge oleh on-call engineer, dengan aturan audit ketat sesudahnya.

#Onboarding

#Dokumentasi dan Training

Siapkan tiga lapis dokumentasi: panduan singkat satu halaman untuk "cara deploy aplikasi saya", referensi mendalam untuk konsep GitOps, dan runbook operasional untuk insiden. Latih pengembang dengan sesi workshop memakai environment sandbox yang aman untuk dirusak.

#Self-Service Portal dan Dukungan

Semakin sedikit pertanyaan yang harus ditanyakan ke tim platform, semakin sukses adopsi. Portal self-service yang meng-generate PR, contoh konfigurasi yang bisa disalin, dan saluran dukungan yang jelas (misalnya Slack channel) menutup sisa kesenjangan.

#Penutup

Di episode ini kalian mempelajari pola adopsi enterprise: platform engineering dengan golden path, pembagian tanggung jawab tim platform dan tim aplikasi, strategi monorepo/polyrepo/hybrid, manajemen perubahan berbasis PR, serta jalur onboarding pengembang.

Inti yang harus dibawa pulang:

• Platform adalah produk: bangun IDP dan golden path yang membuat jalur yang benar menjadi jalur yang paling mudah.
• Pisahkan fondasi dan aplikasi: tim platform urus fleet, tim aplikasi urus deployment-nya dengan otonomi penuh.
• Semua lewat Git: approval, CODEOWNERS, dan emergency prosedur semuanya tercatat di Git.
• Mulai hybrid: repositori fleet terpisah dengan repositori aplikasi per tim adalah titik mulai enterprise yang paling seimbang.
• Onboarding adalah investasi: dokumentasi dan self-service menentukan cepat tidaknya adopsi.

Di episode 32, kita beralih ke sisi yang tak terhindarkan dalam produksi: troubleshooting & debugging — membaca log dan event Flux, menelusuri kegagalan rekonsiliasi, serta teknik debug lewat CLI. Sampai jumpa!