1. GİRİŞ

GitOps, modern bulut ve Kubernetes tabanlı operasyonların yönetiminde hızla kabul gören bir yaklaşımdır. Temel fikir basittir: sistemin istenen durumu (declarative manifest'ler) versiyon kontrol sistemi olarak Git'te tutulur ve bir kontrol düzlemi (controller) bu bildirimi alıp gerçek ortamla sürekli olarak eşler. Bu model, altyapı yönetimini yazılım mühendisliği pratikleriyle hizalayarak tekrar üretilebilirlik, izlenebilirlik ve güvenlik sağlar. 2020'lerin ikinci yarısında GitOps, sürekli teslimatın (CD) doğal bir evrimi olarak algılanıyor; özellikle multi‑cluster, multi‑team ve rapid‑release ortamlarında operasyonel maliyeti düşürüyor.

Bu konu neden konuşuluyor?

• Declarative altyapı ve Kubernetes kullanımı yaygınlaştıkça, manifest'lerin merkezi ve izlenebilir bir yerde tutulması ihtiyacı arttı.
• GitOps, altyapı değişikliklerini kod (infrastructure as code) ile birleştirerek audit, rollback ve PR tabanlı onay süreçleri sağlar.
• Platform ekipleri, developer experience (DX) ve güvenlik için GitOps'u bir araç seti olarak benimsiyor.

Kimler için önemli?

• Platform mühendisleri ve DevOps/ SRE ekipleri
• Kubernetes ile çalışan ekipler ve microservice ortamlarında çalışan mühendisler
• Güvenlik / compliance ekipleri — değişikliklerin audit edilebilmesini isteyenler

Hangi problemleri çözüyor?

• Konfigürasyon drift'i: Git'teki istenen durum ile gerçek durumun uyuşmasını sağlar.
• Rollback ve audit: Tüm değişiklikler Git commit'leriyle izlenir, kolayca geri alınabilir.
• İnsan hatası: PR ve otomatik validasyon süreçleri sayesinde yanlış konfigürasyonun production'a ulaşma riski düşer.

2. KAVRAMSAL TEMELLER

2.1 GitOps tanımı

GitOps, operasyonel süreçlerin Git üzerinde tanımlanması ve bir kontrol düzleminin bu tanımı sürekli olarak gerçek ortama uygulaması felsefesidir. Git, "single source of truth" (tek gerçeklik kaynağı) görevi görür; tüm değişiklikler Git üzerinden yapılır (pull request), otomatik validasyonlardan geçer ve controller bunları cluster'a uygulayıp reconcile eder.

2.2 Temel ilkeler

1. Declarative state: Sistem istenen durum şeklinde tanımlanır (YAML manifest, Kustomize, Helm chart vb.).
2. Git as single source of truth: Konfigürasyon, politika ve manifest'ler Git'te tutulur.
3. Automated reconciliation: Controller (ArgoCD/Flux) Git'i izler ve gerçek durumla istenen durumu eşler.
4. Pull request tabanlı değişim: Tüm değişiklikler kod inceleme, CI validasyonları ve otomatik testlerden geçer.
5. Observability & Safety: Değişikliklerin etkisi telemetry ile izlenir; canary ve policy guardrail'lar uygulanır.

2.3 Kullanılan terminoloji

• Reconcile: Controller'ın gerçek durumu istenen duruma getirmek için yaptığı döngü.
• Manifest: Kubernetes kaynak tanımı (YAML) veya Helm chart.
• Policy as Code: OPA/Conftest ile politikaların kod olarak tanımlanması ve pipeline'da validasyonun sağlanması.
• Environments repo / App repo: Organizasyonel yapılandırmaya göre manifest'lerin ayrıştırıldığı Git repo düzeni.

3. NASIL ÇALIŞIR?

3.1 Sistem mimarisi

GitOps mimarisi üç ana bileşenden oluşur:

1. Git Repos: Application manifests, environment manifests, policy repository. Genelde "app repo" ve "env repo" ayrımı yapılır.
2. Controller / Operator: ArgoCD veya Flux gibi araçlar Git'i izleyip cluster ile reconcile eder.
3. CI ve Validation: Pull request tetiklenince CI devreye girer; lint, unit test, policy check ve manifest validation çalışır. Başarılı ise PR merge edilir ve controller değişikliği uygular.

3.2 Veri akışı

1. Geliştirici/Platform mühendisi PR açar (ör. yeni Helm values veya Kustomize patch).
2. CI pipeline: manifest lint, policy checks (OPA/Conftest), image digest pin ve security scan çalıştırır.
3. PR onaylandıktan sonra değişiklik Git'e merge edilir.
4. Controller (pull model) Git'i algılar ve deployment adımlarını çalıştırır; uygulama veya infra manifest'leri cluster'a apply edilir.
5. Controller reconcile sürecinin sonucu telemetry ve events olarak toplanır; eğer istenen durum elde edilemezse alert tetiklenir veya rollback süreci başlatılır.

3.3 Pull model vs Push model

GitOps'un önemli bir tasarım tercihi "pull model"dir: controller Git'i periyodik olarak veya event‑based olarak kontrol eder ve manifest'leri uygulayacak şekilde hareket eder. Bu model, güvenlik ve audit açısından avantaj sağlar çünkü cluster tarafında bir agent çalışır; merkezi bir CI sunucusunun doğrudan cluster'a push yapmasından farklı olarak erişim sınırları daha belirgindir.

3.4 Environment stratejileri

• Mono‑repo vs Multi‑repo: Tek repo tüm uygulama ve environment manifest'lerini barındırabilir (mono‑repo) veya uygulama başına ve environment başına repo'lar (multi‑repo) tercih edilebilir. Kuruluşun ölçeğine göre karar verin.
• App of Apps pattern: Bir üst seviye GitOps uygulaması ile alt uygulamaların manifest'lerini yönetmek (ArgoCD'de yaygın).

4. GERÇEK DÜNYA KULLANIMLARI

Netflix & Canary / Progressive Delivery

Netflix tipi organizasyonlarda GitOps, canary ve progressive delivery stratejileri ile birleşir. Manifest'lerde canary rollout kuralları, service mesh konfigürasyonları ve traffic splitting ifadeleri tanımlanır; controller bunları uygulayıp metric'leri izler.

Uber — Multi‑cluster ve Bölgesel Yönetim

Uber gibi global hizmet sağlayıcıları GitOps ile cluster'ları ve region‑specific konfigürasyonları yönetir. Repo düzeni ve bootstrap süreçleri ile yeni cluster'ların otomatik kurulması sağlanır.

Amazon / Büyük Kuruluşlar — Policy & Compliance

Policy as code (OPA), admission controller'lar ve otomatik policy validation ile GitOps organizasyonlarda compliance sağlamak için kullanılır. Deploy öncesi ve runtime policy kontrolleri gereksinimleri karşılar.

OpenAI / MLOps — Model ve Inference Config

MLOps bağlamında GitOps, model rolloutlarını, config'leri (serving config, replica counts) ve canary inference adımlarını yönetmek için kullanılır. Model metadata ve model registry ile entegrasyon önem kazanır.

Stripe / Fintech — Audit ve Rollback

Finansal uygulamalarda GitOps'un sağladığı audit trail ve PR tabanlı onay süreçleri kritik önemdedir. Değişikliklerin kim tarafından ve ne zaman yapıldığı kaydedilir; gerekli durumlarda hızlı rollback yapılır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Tekrar üretilebilirlik: İstenilen durum Git'te saklandığı için her zaman aynı ortamı yeniden oluşturabilirsiniz.
• Audit ve traceability: Tüm değişiklikler commit, PR ve pipeline geçmişiyle izlenebilir.
• Güvenlik: Pull model ve least‑privilege ilkesi ile erişimler daha kontrollü olur.
• Developer Experience: Geliştiriciler için tek araç (Git) üzerinden altyapı değişiklikleri yapmak doğal bir iş akışı sunar.

Sınırlamalar

• İlk kurulum maliyeti: Repo düzeni, CI validasyonları, policy kontrolleri ve controller bootstrap süreçleri başlangıç maliyeti getirir.
• Operasyonel karmaşıklık: Multi‑cluster, multi‑team senaryolarında senkronizasyon, secrets yönetimi ve config drift yönetimi karmaşıklaşabilir.
• Tooling bağımlılığı: ArgoCD veya Flux gibi araçların yetenek ve sürümlere bağlı sorunları olabilir; upgrade stratejileri planlanmalı.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Repository ve yapı

• Repo stratejinizi netleştirin (mono‑repo vs multi‑repo) ve dokümante edin.
• Manifest'leri environment bazlı ayırın; secrets'ı Git dışında tutun (Vault, SealedSecrets, External Secrets).
• App of Apps pattern ile ölçeklenebilir bir yönetim katmanı kurun.

CI & Validation

• PR açıldığında manifest lint, policy as code (OPA/Conftest) ve image digest pin kontrolü çalıştırın.
• Security scanning ve SBOM (Software Bill of Materials) üretimini entegre edin.

Security & Compliance

• Least privilege ile controller ve cluster rol/rolebinding'lerini sınırlayın.
• Admission controller'lar ile runtime policy uygulayın (OPA Gatekeeper).

Observability ve Operasyon

• Reconcile döngüleri, events ve controller log'ları için merkezi log ve metric toplayıcı kurun.
• Canary metric'leri ve otomatik rollback mekanizmalarını entegre edin.

8. SIK YAPILAN HATALAR

• Secrets'ı doğrudan Git'te tutmak: güvenlik riski oluşturur.
• PR sürecini atlamak: doğrudan merge/force push ile GitOps faydalarını kaybedersiniz.
• Controller'ı üretim cluster'ına fazla yetkiyle koymak: principle of least privilege ihmal edilir.
• Manifest'leri temize çekmemek: environment-specific kopyalar ve duplication teknik borç yaratır.

9. GELECEK TRENDLER

1. Policy‑driven GitOps: Policy as code daha sıkı entegre olacak, otomatik compliance flow'ları doğacak.
2. Multi‑cluster control planes: Model driven orchestrator'lar ve federated GitOps yaklaşımları yaygınlaşacak.
3. AI destekli manifest optimizasyonu: ML tabanlı öneriler, drift tespit ve rollback tavsiyeleri artacak.
4. GitOps for edge: IoT ve edge device yönetimi için lightweight GitOps agent'lar gelişecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. GitOps başlamadan önce nelere hazır olmam gerekir?

   Declarative manifests (Helm/Kustomize), IaC, secrets yönetimi (Vault/SealedSecrets), ve CI pipeline'larında manifest validation için altyapı hazır olmalıdır. Ayrıca organizasyonel süreçler (PR review, owner atama) tanımlanmalıdır.

2. ArgoCD mi yoksa Flux mu seçmeliyim?

   Her iki araç da olgun çözümlerdir. ArgoCD zengin UI ve app‑of‑apps pattern desteğiyle popülerdir; Flux daha Git-centric ve lightweight bir mimariye sahiptir. Seçim organizasyon ihtiyaçlarına göre yapılmalıdır.

3. Secrets'ı nasıl güvenli tutarım?

   Secrets'ı Git'te tutmayın. External Secrets, SealedSecrets (controller ile şifreli secret), veya HashiCorp Vault gibi çözümler kullanın. Daha güvenli model: secret temelli erişimi runtime'da sağlayın, manifest içinde referanslarla belirtin.

4. GitOps multi‑tenant kurgular için uygun mu?

   Evet, uygun ancak tenant izolasyonu, RBAC, policy as code ve maliyet tahsis mekanizmaları doğru planlanmalıdır.

5. GitOps ile rollback nasıl yapılır?

   Git'e önceki commit revert veya yeni commit ile eski manifest durumu geri yüklenerek yapılır. Controller bunu algılar ve cluster'ı eski duruma reconcile eder. Database migration gibi stateful rollback senaryolarında ek planlama gerekir.

6. GitOps pipeline'larını nasıl test ederim?

   PR pipeline'larında manifest lint, kustomize build, helm template, policy as code ve dry‑run apply (kubectl diff veya kubeval) gibi adımlar çalıştırın. Integration test'ler için ephemeral cluster (kind, kind + test infra) kullanılabilir.

7. GitOps performans sorunları yaşanır mı?

   Büyük repo ve çok sık değişikliklerde controller reconcile maliyeti olabilir. Repo tasarımı, app partitioning ve controller scaling ile bu sorun yönetilir.

8. GitOps'u yavaşça nasıl devreye alırım?

   Küçük bir servis veya non‑critical environment ile başlayın; app of apps pattern ve pilot cluster'lar kurun. Başarı örneklerini çoğaltarak yaygınlaştırın.

Anahtar Kavramlar

GitOps

Git'i tek kaynak olarak kullanıp, deklaratif manifest'leri controller ile reconcile eden operasyon yaklaşımı.

Reconcile

Controller'ın istenen durumu gerçek durumla uyumlu hale getirme döngüsü.

Policy as Code

Uyumluluk ve güvenlik kurallarının kod olarak ifade edilmesi ve pipeline içinde validasyonunun yapılması.

App of Apps

Üst seviye bir GitOps uygulaması ile alt uygulama repo'larını yönetme deseni.

Pull Model

Controller'ın Git'ten periyodik veya event‑based olarak çektiği ve apply ettiği model.

Öğrenme Yol Haritası

1. 0–1 ay: Kubernetes temel kavramları, declarative manifests (YAML), Helm ve Kustomize öğrenin.
2. 1–3 ay: GitOps araçları (ArgoCD/Flux) kurulum ve temel kullanım; küçük bir uygulamayı GitOps ile deploy edin.
3. 3–6 ay: Policy as Code (OPA/Gatekeeper), secrets yönetimi (Vault/SealedSecrets) ve CI validasyon adımları ekleyin.
4. 6–12 ay: Multi‑cluster GitOps, App of Apps pattern, canary automation ve observability entegrasyonunu hayata geçirin.
5. 12+ ay: GitOps for edge, federated GitOps ve AI destekli manifest optimizasyonu konularında deneyim kazanın.