Belajar GitOps dengan ArgoCD - Sync Windows & Scheduling

#Pendahuluan

Di episode 13 sebelumnya kita menguasai Resource Hooks untuk mengontrol apa yang terjadi selama sync. Tapi ada pertanyaan yang lebih dasar: kapan sync itu sendiri boleh terjadi? Malam hari ketika semua user aktif di blokir? Freeze rilis seminggu sebelum audit? Jam maintenance penuh risiko? ArgoCD menyediakan jawaban bernama Sync Windows — jendela waktu terjadwal yang membolehkan atau melarang operasi sync, baik otomatis maupun manual.

Mengapa ini penting? GitOps memanjakan kita dengan auto-sync, tapi tidak semua perubahan aman di semua waktu. Sync Windows adalah mekanisme tata kelola (governance) yang memindahkan keputusan "jam berapa deploy" dari ingatan manusia ke konfigurasi yang deterministik — bagian dari budaya change management yang akan kita dalami di episode 15.

#Konsep Dasar

Sync Window adalah aturan pada AppProject dengan tiga komponen utama:

• kind — allow (izinkan sync) atau deny (larang sync).
• schedule — kapan jendela aktif, dalam format cron 5 bidang (menit, jam, tanggal, bulan, hari).
• duration — berapa lama jendela berlangsung setelah schedule tercapai.

Window bisa disaring (scoped) ke applications, namespaces, dan clusters tertentu, dengan dukungan wildcard.

#Aturan Evaluasi

• Jika tidak ada window yang cocok dengan sebuah aplikasi → semua sync diizinkan.
• Jika ada window allow yang cocok → sync hanya diizinkan ketika window allow aktif.
• Jika window deny cocok dan aktif → sync ditolak, bahkan jika window allow juga aktif. deny selalu menang.

#Konfigurasi via AppProject

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: billing-prod
spec:
  syncWindows:
    - kind: allow
      schedule: "0 9 * * *"
      duration: 2h
      applications:
        - "*-prod"
      namespaces:
        - billing-prod
      clusters:
        - in-cluster
      manualSync: true
    - kind: deny
      schedule: "0 22 * * *"
      duration: 2h
      timeZone: Asia/Jakarta
      applications:
        - "*-prod"

Contoh di atas: aplikasi *-prod boleh sync otomatis setiap hari pukul 09.00–11.00 (dan manual kapan pun, berkat manualSync: true), tapi dilarang sync pukul 22.00–24.00 — periode yang biasa dipakai untuk maintenance atau meminimalkan risiko rilis malam.

#Mengelola Window via CLI

Semua operasi window tersedia di CLI:

argocd proj windows add billing-prod \
  --kind deny --schedule "0 22 * * *" --duration 2h \
  --applications "*-prod"
argocd proj windows list billing-prod
argocd proj windows delete billing-prod <ID>

Output argocd proj windows list menampilkan kolom ID, STATUS, KIND, SCHEDULE, DURATION, hingga MANUALSYNC dan SYNCOVERRUN — berguna untuk memverifikasi jadwal sebelum rilis besar.

#Use Case

#Maintenance Windows

Jadwal deny selama jam maintenance (misal 0 2 * * Sun, durasi 3 jam) mencegah auto-sync mengganggu pekerjaan perawatan database. Ditambah syncOverrun: true, sync yang sudah berjalan tidak dipotong paksa di tengah.

#Business Hours Restriction

Pola allow hanya di jam kantor, misalnya 0 9 * * 1-5 durasi 8 jam — di luar itu aplikasi tidak bisa berubah tanpa persetujuan eksplisit.

#Change Freeze

Menjelang peluncuran besar atau audit, pasang deny selama seminggu penuh:

    - kind: deny
      schedule: "0 0 * * *"
      duration: 24h
      applications:
        - "*-prod"
      clusters:
        - eks-prod

#Scheduled Deployments

Kombinasi allow + syncOverrun memungkinkan jendela deploy terjadwal — tim production hanya menerima perubahan dalam jendela yang disepakati, memudahkan koordinasi dengan on-call.

#Timezone & Multiple Windows

• Timezone — field timeZone (misal Asia/Jakarta) mengatur basis interpretasi schedule. Tanpa field ini, schedule mengikuti zona waktu server ArgoCD (disarankan disetel UTC).
• Multiple windows — satu project bisa punya banyak window allow dan deny; semuanya dievaluasi bersama dengan aturan di atas.
• Operator AND — jika sebuah window punya lebih dari satu filter (applications dan namespaces), defaultnya di-OR-kan. Aktifkan useAndOperator: true bila semua kondisi harus dipenuhi bersamaan.

#Manual Override & Emergency Deployment

Saat window deny aktif, sync diblokir — termasuk manual. Untuk skenario darurat, ArgoCD menyediakan override eksplisit:

argocd proj windows list billing-prod
argocd proj windows enable-manual-sync billing-prod <ID>
argocd proj windows disable-manual-sync billing-prod <ID>

manualSync: true pada sebuah window (atau enable-manual-sync via CLI) membuat sync manual tetap diizinkan meski window deny aktif — ideal untuk hotfix darurat, sementara auto-sync tetap terkunci.

#Kesalahan Umum (Common Pitfalls)

1. Lupa bahwa deny menimpa allow. Window allow tidak mengesampingkan deny yang aktif; ekspektasi salah ini sering membuat tim heran mengapa sync tetap diblokir.
2. Schedule cron salah interpretasi. Format cron ArgoCD 5 bidang: 0 22 * * * = pukul 22.00 setiap hari. Uji dengan argocd proj windows list untuk melihat STATUS.
3. Timezone tidak disetel. Server di UTC tapi tim di Jakarta → window "22.00" berarti 05.00 pagi WIB. Selalu set timeZone.
4. manualSync aktif di semua window. Jika tujuannya mencegah perubahan produksi, jangan beri manualSync: true — override darurat harus eksplisit dan sementara.
5. Sync overrun tidak diaktifkan. Tanpa syncOverrun, sync panjang bisa diputus paksa saat window berakhir dan meninggalkan state aneh.

#Penutup

Episode ini memberi kalian kendali penuh atas kapan perubahan boleh terjadi: konsep allow/deny, jadwal cron dan durasi, pemfilteran per aplikasi/namespace/cluster, use case maintenance window, business hours, change freeze, dan scheduled deployment, penanganan timezone dan banyak window, serta override manual untuk emergency deployment.

Poin yang harus kalian bawa:

• Sync Windows hidup di AppProject dan berlaku untuk seluruh Application dalam project.
• deny selalu menimpa allow saat keduanya aktif.
• manualSync: true adalah mekanisme override darurat — gunakan dengan bijak.
• timeZone penting agar jadwal sesuai dengan zona kerja tim.
• syncOverrun mencegah sync yang berjalan terpotong oleh pergantian window.

Mengatur kapan deploy hanyalah setengah dari tata kelola; setengah lainnya adalah bagaimana perubahan mengalir melalui Git. Di episode 15 selanjutnya kita membahas GitOps Workflow & Branch Strategies: trunk-based vs GitFlow, struktur direktori environment, strategi promosi branch/tag, dan change management berbasis PR. Sampai jumpa di episode 15!