Git Branching ve GitOps Nedir?

Modern yazılım mühendisliğinde yüzlerce geliştiricinin aynı kod tabanı (codebase) üzerinde birbirinin işini bozmadan, çakışmalar (merge conflicts) yüzünden haftalarca kilitlenmeden ve canlı ortamı (production) riske atmadan çalışabilmesi, seçilen Git dallanma stratejisi (Git Branching Strategy) ve dağıtım mimarisiyle doğrudan ilişkilidir. On yıl önce yılda birkaç kez büyük sürüm çıkaran monolitik yazılım ekipleri için tasarlanan dallanma modelleri, bugün günde onlarca kez canlıya kod gönderen mikroservis ve bulut-yerel (cloud-native) organizasyonlarda ciddi darboğazlara yol açmaktadır. Bununla birlikte, sadece uygulama kodunun değil, Kubernetes kümelerinin ve bulut altyapısının da Git üzerinden bildirimsel (declarative) olarak yönetilmesini sağlayan GitOps paradigması, yazılım teslimat süreçlerini kökten değiştirmiştir. Uygulama ve yazılım mimarileri dünyasında mühendislik hızını (developer velocity) ve sistem kararlılığını belirleyen bu iki temel disiplini; Git Flow, GitHub Flow ve Trunk-Based Development karşılaştırmalarından Pull Request kültürünün inceliklerine, Semantic Versioning standartlarından ArgoCD ve Flux tabanlı GitOps mimarisine kadar tüm teknik derinliğiyle inceliyoruz.

1. Versiyon Kontrolünde Dallanma (Branching) Neden Stratejik Bir Karardır?

Git, dağıtık versiyon kontrol sistemi (DVCS) olarak dallanma (branching) ve birleştirme (merging) işlemlerini milisaniyeler içinde gerçekleştirecek şekilde tasarlanmıştır. SVN (Subversion) veya CVS gibi eski merkezi versiyon kontrol sistemlerinde yeni bir dal açmak tüm dizin ağacının sunucu üzerinde fiziksel olarak kopyalanmasını gerektirirken, Git'te bir dal (branch) yalnızca 40 karakterlik bir SHA-1 commit özetini (hash) işaret eden 41 baytlık hafif bir metin dosyasıdır (pointer). Ancak teknik olarak yeni bir dal açmanın bu kadar ucuz olması, organizasyonel olarak uzun ömürlü dalları yönetmenin de ucuz olduğu anlamına gelmez.

Bir geliştirici ana daldan (main veya trunk) ayrılıp kendi özellik dalında (feature branch) üç hafta boyunca izole şekilde çalıştığında, diğer ekip üyeleri ana dala yüzlerce yeni commit ekler. Üç haftanın sonunda geliştirici kodunu ana dalla birleştirmek istediğinde, yazılım dünyasında "Merge Hell" (Birleştirme Cehennemi) olarak adlandırılan yıkıcı senaryo ortaya çıkar. Merge Hell yalnızca sözdizimsel (syntactic) satır çakışmalarından ibaret değildir; çok daha tehlikeli olanı anlamsal çakışmalardır (semantic conflicts). İki farklı geliştirici tamamen farklı dosyalarda değişiklik yapmış olabilir ve Git bu iki dalı hiçbir sözdizimsel hata vermeden otomatik olarak birleştirebilir. Fakat bir geliştiricinin değiştirdiği fonksiyon imzası, veri sözleşmesi veya iş kuralı, diğer geliştiricinin yazdığı modülün çalışma zamanı (runtime) varsayımlarını bozduğunda, sorun ancak canlı ortamda veya entegrasyon testlerinde patlak verir. Özellikle bulut tabanlı SaaS ve yüksek ölçekli e-ticaret sistemleri gibi kesintisiz çalışması gereken platformlarda, dallanma stratejisi yalnızca bir Git kullanımı tercihi değil, doğrudan DORA (DevOps Research and Assessment) metriklerini belirleyen mimari bir karardır.

DORA araştırmalarına göre elit yazılım ekiplerini düşük performanslı ekiplerden ayıran dört temel metrik vardır: Dağıtım Sıklığı (Deployment Frequency), Değişiklikler İçin Teslim Süresi (Lead Time for Changes), Değişiklik Başarısızlık Oranı (Change Failure Rate) ve Hizmeti Geri Yükleme Süresi (Mean Time to Recovery - MTTR). Uzun yaşayan izole dallar teslim süresini (Lead Time) haftalara çıkarırken, devasa boyutlu birleştirmeler değişiklik başarısızlık oranını (Change Failure Rate) katlayarak artırır. Bu nedenle modern yazılım mühendisliğinde hedef, dalların ömrünü saatler seviyesine indirmek ve entegrasyonu sürekli hale getirmektir.

2. Git Branching Stratejileri: Git Flow, GitHub Flow ve Trunk-Based Development

Yazılım endüstrisinde ekiplerin büyüklüğüne, ürünün dağıtım modeline (kutulu/sürümlü yazılım vs. sürekli güncellenen SaaS) ve test otomasyonu olgunluğuna göre üç ana dallanma stratejisi öne çıkmaktadır. Her stratejinin çözdüğü problem uzayı ve getirdiği operasyonel maliyet birbirinden farklıdır.

2.1. Git Flow: Sürümlü Yazılımlar İçin Klasik Model

2010 yılında Vincent Driessen tarafından tanımlanan Git Flow, uzun yıllar boyunca kurumsal yazılım ekiplerinin varsayılan standardı olmuştur. Bu modelde iki ana ömür boyu yaşayan dal bulunur: yalnızca canlıdaki resmi sürümleri temsil eden main (eski adıyla master) ve bir sonraki sürüm için geliştirilen tüm kodların toplandığı develop dalı. Bunlara ek olarak üç yardımcı dal türü kullanılır:

• Feature Branches (feature/*): develop dalından açılır, yeni özellik tamamlandığında tekrar develop dalına birleştirilir. Çoğu zaman geliştiricinin bilgisayarında veya uzak depoda günlerce ya da haftalarca yaşar.
• Release Branches (release/*): Yeni bir sürüm çıkmaya yakın develop dalından açılır (örneğin release/2.4.0). Burada kesinlikle yeni özellik eklenmez; yalnızca son hata düzeltmeleri, sürüm numarası güncellemeleri, dokümantasyon hazırlıkları ve manuel/otomatik regresyon testleri yapılır. Tamamlandığında hem main dalına (etiketlenerek) hem de develop dalına birleştirilir.
• Hotfix Branches (hotfix/*): Canlı ortamda (main) müşterileri etkileyen acil bir kritik hata çıktığında doğrudan main dalından açılır. O sırada develop dalında henüz tamamlanmamış kararsız özellikler olabileceği için develop dalına dokunulmaz. Sorun çözülünce hem main hem de develop dalına birleştirilir.

Git Flow; mobil uygulamalar (App Store / Google Play onay süreçleri olan), masaüstü yazılımları, gömülü sistemler (IoT firmware) veya müşteriye yerinde (on-premise) kurulan ve aynı anda birden fazla eski sürümün (örneğin v1.4, v2.0, v2.1) güvenlik yamalarıyla desteklenmesi gereken yazılımlar için hala geçerlidir. Ancak bizzat yaratıcısı Vincent Driessen bile 2020 yılında yayınladığı resmi değerlendirmede, günde birden fazla kez canlıya çıkan modern web ve bulut uygulamaları için Git Flow'un aşırı bürokratik olduğunu ve Trunk-Based veya GitHub Flow modellerinin tercih edilmesi gerektiğini açıkça vurgulamıştır.

2.2. GitHub Flow: Basitlik ve Sürekli Dağıtım

Git Flow'un getirdiği develop ve release dallarının karmaşasını ortadan kaldırmak için GitHub tarafından popülerleştirilen bu modelde tek bir uzun ömürlü dal vardır: main. Temel kural son derece nettir: main dalındaki her commit her an canlıya alınabilir (production-ready) durumda olmalıdır. Süreç şu adımlarla işler:

1. Geliştirici main dalının en güncel halinden açıklayıcı bir isimle yeni bir dal açar (örneğin feat/odeme-3d-secure-entegrasyonu veya fix/sepet-kdv-hesaplama).
2. Değişikliklerini bu dal üzerinde küçük ve anlamlı commit'ler halinde yapar, düzenli olarak uzak sunucuya (origin) iter.
3. İş tamamlandığında veya erken aşamada mimari geri bildirim almak istediğinde (Draft PR olarak) bir Pull Request (PR) veya Merge Request (MR) açar.
4. Otomatik CI (Continuous Integration) boru hattı birim testlerini, entegrasyon testlerini ve güvenlik taramalarını çalıştırır; ekip arkadaşları kodu inceler (Code Review) ve onaylar.
5. Kod main dalına birleştirilir ve derhal (veya otomatik CD boru hattıyla) canlı ortama dağıtılır.

2.3. Trunk-Based Development (TBD): Yüksek Performanslı Ekiplerin Sırrı

Google, Meta, Netflix, Spotify gibi teknoloji devlerinin ve DORA raporlarında "Elit Performanslı" kategorisinde yer alan mühendislik organizasyonlarının temel standardı Trunk-Based Development (Ana Gövde Odaklı Geliştirme) modelidir. Bu yaklaşımda geliştiriciler ya doğrudan trunk (main) dalına küçük commit'ler atar ya da en fazla birkaç saat (kesinlikle 1-2 günü geçmeyen) yaşayan çok kısa ömürlü özellik dalları (short-lived feature branches) kullanırlar.

Peki geliştirilmesi üç hafta sürecek kapsamlı bir ödeme sistemi yenilemesi, günde birkaç kez main dalına birleştirilirken canlıdaki kullanıcıları nasıl etkilemez? İşte burada Feature Flags (Özellik Bayrakları / Feature Toggles), Keystone Interface ve Branch by Abstraction (Soyutlama ile Dallanma) teknikleri devreye girer. Tamamlanmamış yeni kod canlı ortama gider ancak çalışma zamanında bir yapılandırma bayrağı (örneğin LaunchDarkly, Unleash, Flagsmith veya kendi veritabanınızdaki ENABLE_NEW_CHECKOUT_ENGINE=false) arkasında pasif durur. Böylece:

• Kod tabanı her gün tüm ekip tarafından sürekli entegre edilir, Merge Hell tamamen ortadan kalkar.
• Yeni kod oluşturulurken eski kodla yan yana yaşar; arayüz (interface) seviyesinde soyutlama yapılarak hem eski hem yeni implementasyon birim testleriyle doğrulanır.
• Özellik tamamlandığında yeni bir dağıtım (deployment) yapmaya gerek kalmadan, yalnızca bayrak açılarak (örneğin önce sadece şirket içi QA ekibine, sonra Türkiye'deki kullanıcıların %5'ine - Canary Release) özellik kademeli olarak aktif edilir.
• Canlıda beklenmedik bir bellek sızıntısı veya veritabanı darboğazı yaşandığında, kodu geri almak (rollback/revert) ve yeniden derleme beklemek yerine milisaniyeler içinde bayrak kapatılarak (Kill Switch) sistem güvenli duruma döndürülür.

Karşılaştırma Kriteri	Git Flow	GitHub Flow	Trunk-Based Development (TBD)
Uzun Ömürlü Dallar	main ve develop (2 adet)	Yalnızca main (1 adet)	Yalnızca main / trunk (1 adet)
Özellik Dalı Ömrü	Günler veya haftalar	Birkaç gün (1 - 4 gün)	Birkaç saat (maksimum 1 gün)
Birleştirme Çakışması (Merge Conflict) Riski	Çok Yüksek (Merge Hell riski)	Orta / Düşük	Minimum (Sürekli küçük entegrasyon)
Feature Flag İhtiyacı	Düşük (İzolasyon dallarla sağlanır)	Orta	Zorunlu (Tamamlanmamış kodu gizlemek için)
CI/CD ve Test Otomasyonu Gereksinimi	Orta (Release dalında manuel test yapılabilir)	Yüksek	Çok Yüksek (Tam otomatik kalite kapıları şarttır)
En Uygun Kullanım Senaryosu	Kutulu yazılımlar, mobil uygulamalar, çoklu eski sürüm desteği	Standart web uygulamaları, orta ölçekli SaaS ekipleri	Yüksek hızlı mikroservisler, Elit DevOps ve sürekli teslimat ekipleri

3. Pull Request (PR), Code Review ve Merge Queue Mimarisi

Modern yazılım geliştirmede Pull Request (veya GitLab ekosisteminde Merge Request), yalnızca kodun bir daldan diğerine kopyalanması işlemi değil; mimari bilginin ekip içinde yayıldığı (kolektif kod sahipliği), potansiyel güvenlik açıklarının yakalandığı ve teknik borcun (technical debt) kontrol altında tutulduğu en kritik kalite kapısıdır. Ancak yanlış yönetilen bir PR süreci, geliştiricilerin günlerce onay beklediği ve sürekli bağlam değiştirmek (context switching) zorunda kaldığı bir verimlilik katiline dönüşebilir.

3.1. Küçük ve Atomik PR Kuralı

SmartBear ve Cisco tarafından yürütülen kapsamlı yazılım mühendisliği araştırmaları, bir kod incelemesinde (Code Review) incelenen satır sayısı 200-400 aralığını geçtiğinde, inceleyicinin (reviewer) mantıksal hata bulma oranının dramatik biçimde düştüğünü kanıtlamaktadır. 1.500 satırlık devasa bir PR açıldığında inceleyici genellikle bilişsel yorgunluk (cognitive overload) yaşar, kodu derinlemesine analiz edemez ve yüzeysel bir bakışla "LGTM (Looks Good To Me)" yazarak onaylar. Oysa 10 satırlık bir PR'da herkes ince detayları görürken, 1.500 satırlık PR'da kritik hatalar gözden kaçar. Bu nedenle büyük bir özellik; veritabanı şema değişikliği PR'ı, arka uç servis katmanı PR'ı, API uç noktası PR'ı ve ön yüz bileşeni PR'ı olmak üzere birbirinden bağımsız test edilebilir Stacked PRs (Yığınlanmış PR'lar) veya atomik parçalar halinde gönderilmelidir. Özellikle yapay zeka destekli kod analizi ve tersine mühendislik araçlarının CI boru hatlarına entegre edilmesiyle birlikte, küçük PR'lar hem statik analiz ajanları hem de insan inceleyiciler tarafından çok daha yüksek doğrulukla denetlenmektedir.

3.2. Otomatik Kalite Kapıları (Automated Quality Gates) ve Git Hooks

İnsan inceleyicilerin değerli mühendislik zamanı, noktalı virgül eksikliği, girinti (indentation) hatası, alfabetik sıralanmamış import satırları veya kullanılmayan değişkenleri bulmak için harcanmamalıdır. Bu kontroller iki aşamada tam otomatik hale getirilmelidir:

• Yerel Pre-Commit Kancaları (Husky, lint-staged, pre-commit): Geliştirici kendi bilgisayarında git commit komutunu çalıştırdığı anda, yalnızca değişen dosyalar üzerinde (lint-staged) Prettier, ESLint, Black veya Ruff çalışarak kodu otomatik formatlar ve bariz sözdizimi hatalarını daha uzak sunucuya gitmeden engeller.
• CI Kalite Kapıları: PR açıldığı anda CI sunucusu (GitHub Actions, GitLab CI, Buildkite) tip kontrolünü (tsc --noEmit), birim ve entegrasyon testlerini, kod kapsama (coverage) eşiklerini, lisans uyumluluğunu ve SAST / Secret Scanning (SonarQube, Semgrep, Snyk, TruffleHog) güvenlik taramalarını çalıştırır. Herhangi bir kontrol başarısız olursa birleştirme (Merge) butonu teknik olarak kilitlenir.

3.3. Büyük Ekiplerde "Broken Main" Sorunu ve Merge Queue Çözümü

50'den fazla geliştiricinin aynı anda çalıştığı bir depoda sıkça yaşanan sinsi bir problem vardır: Geliştirici A'nın PR'ı tüm testlerden yeşil geçer. Aynı anda Geliştirici B'nin PR'ı da kendi dalında tüm testlerden yeşil geçer. Geliştirici A PR'ını main dalına birleştirir. İki dakika sonra Geliştirici B de kendi PR'ını birleştirir. Ancak A'nın yaptığı değişiklik ile B'nin yaptığı değişiklik bir araya geldiğinde main dalındaki derleme kırılır! Çünkü B'nin PR'ı, A'nın son birleştirdiği kodla birlikte test edilmemiştir.

Bu sorunu çözmek için GitHub Merge Queue, GitLab Merge Trains veya Bors-ng gibi Birleştirme Kuyruğu (Merge Queue) sistemleri kullanılır. Bir PR onaylandığında doğrudan main dalına yazılmaz; kuyruğa girer. Sistem arka planda geçici bir birleştirme dalı oluşturarak PR'ı kuyruktaki kendisinden önceki tüm PR'larla ve main dalının en son haliyle birleştirip CI testlerini son kez koşturur. Testler geçerse main dalına atomik olarak eklenir; başarısız olursa o PR kuyruktan çıkarılır ve main dalı her zaman %100 yeşil (çalışır) kalır.

4. Conventional Commits ve Semantic Versioning (SemVer) Otomasyonu

Git geçmişine bakıldığında "fix", "son degisiklikler", "calisiyor", "pr yorumlari duzeltildi" gibi anlamsız commit mesajları görmek, üretimdeki bir hatanın hangi değişiklikten kaynaklandığını bulmaya çalışırken (git log veya git bisect süreçlerinde) büyük zaman kaybına yol açar. Bunu önlemek için modern yazılım ekipleri Conventional Commits (Geleneksel Commit) spesifikasyonunu ve commitlint doğrulamasını uygular.

Bu standartta her commit mesajı makine tarafından okunabilir katı bir yapıya sahiptir: <tip>(<kapsam>): <açıklama>. Örneğin:

• feat(auth): OAuth2 PKCE akışı ve refresh token rotasyonu eklendi (Yeni bir özellik - SemVer standardında MINOR sürüm artışını tetikler: 1.2.0 -> 1.3.0).
• fix(cart): indirim kuponu hesaplamasındaki kuruş yuvarlama hatası giderildi (Hata düzeltmesi - SemVer standardında PATCH sürüm artışını tetikler: 1.2.0 -> 1.2.1).
• feat(api)!: v1 sipariş uç noktası kaldırıldı, v2 şemasına geçildi (Ünlem işareti veya commit alt bilgisinde BREAKING CHANGE: ifadesi geriye dönük uyumsuzluğu belirtir - SemVer standardında MAJOR sürüm artışını tetikler: 1.2.0 -> 2.0.0).
• chore(deps):, docs(readme):, refactor(payment):, perf(query):, test(order):, ci(github): gibi diğer önekler ise sürüm numarasını doğrudan değiştirmeyen ancak CHANGELOG.md (Sürüm Notları) dosyasında ilgili başlıklar altında otomatik sınıflandırılan değişiklikleri ifade eder.

Semantic Release veya Google tarafından geliştirilen Release Please gibi araçlar, main dalına birleştirilen bu yapılandırılmış commit mesajlarını analiz ederek insan müdahalesi olmadan bir sonraki sürüm numarasını hesaplar, otomatik sürüm PR'ı açar, Git etiketini (Tag) oluşturur, CHANGELOG.md dosyasını günceller ve derlenen paketi (Docker imajı, npm paketi, PyPI paketi veya Go modülü) otomatik olarak yayınlar.

5. GitOps Nedir? CI/CD'den Bildirimsel Altyapı Senkronizasyonuna Geçiş

2017 yılında Weaveworks tarafından ortaya atılan ve bugün Cloud Native Computing Foundation (CNCF) altında endüstri standardı haline gelen GitOps kavramı, Git'i yalnızca uygulama kaynak kodunun değil, aynı zamanda tüm altyapı, ağ kuralları ve uygulama dağıtım durumunun (deployment state) Tek Doğruluk Kaynağı (Single Source of Truth) haline getiren operasyonel bir çerçevedir.

5.1. Geleneksel Push-Tabanlı CI/CD'nin Güvenlik ve Tutarlılık Sorunları

Geleneksel CI/CD boru hatlarında (CIOps / Push modeli), uygulama kodu derlendikten ve Docker imajı oluşturulduktan sonra, CI sunucusu (örneğin Jenkins, GitLab Runner veya GitHub Actions) son adımda kubectl apply -f deployment.yaml veya helm upgrade --install komutunu çalıştırarak değişikliği üretim (production) Kubernetes kümesine dışarıdan "iter" (push). Bu yaklaşımın kurumsal ölçekte üç büyük mimari zaafı vardır:

1. Güvenlik Riski (God-Mode Credentials): Dışarıdaki bir CI sunucusunun canlı Kubernetes kümesine dağıtım yapabilmesi için kümenin tam yetkili (cluster-admin) API anahtarlarına ve ağ erişimine sahip olması gerekir. Üçüncü parti bir CI platformunda yaşanacak bir güvenlik ihlali, saldırganların tüm canlı veritabanlarınıza ve üretim kümelerinize doğrudan yönetici erişimi kazanması anlamına gelir.
2. Configuration Drift (Yapılandırma Kayması): Bir sistem mühendisi gece yarısı acil bir performans sorununu çözmek için doğrudan canlı kümeye bağlanıp kubectl edit deployment ile replika sayısını veya bellek limitini değiştirdiğinde, canlı ortam (Actual State) ile Git deposundaki tanım (Desired State) birbirinden kopar. Bir sonraki dağıtımda bu manuel düzeltme ezilir ve kriz tekrar yaşanır.
3. Durum Görünürlüğü ve Kısmi Başarısızlıklar: CI betiği kubectl apply komutunu çalıştırıp "0" çıkış koduyla başarılı görünse bile, Kubernetes içinde Pod'ların yeni imajı çekerken ImagePullBackOff veya başlangıçta CrashLoopBackOff durumuna düşüp düşmediğini sürekli izleyen bir geri bildirim döngüsü yoktur.

5.2. Pull-Tabanlı GitOps Mimarisi ve 4 Temel İlke

OpenGitOps (CNCF) standartlarına göre gerçek bir GitOps mimarisi dört temel ilkeye dayanır:

• 1. Bildirimsel Tanımlama (Declarative): Sistemin nasıl kurulacağı adım adım betiklerle (imperative) değil, sistemin sonunda hangi durumda olması gerektiği (Desired State) Kubernetes YAML manifestoları, Helm şemaları veya Kustomize katmanları olarak bildirimsel biçimde tanımlanır.
• 2. Sürümü Yönetilen ve Değiştirilemez Depolama (Versioned and Immutable): İstenen durum (Desired State), tüm değişiklik geçmişinin kriptografik commit özetleriyle (SHA), kimin, ne zaman ve hangi PR onayıyla değiştirdiği bilgisiyle birlikte Git deposunda saklanır. Bu özellik, finans ve bankacılık gibi regüle sektörlerde (SOC2, ISO 27001, PCI-DSS) kusursuz bir denetim izi (Audit Trail) sağlar.
• 3. Otomatik Çekme (Pulled Automatically): Dışarıdan kümeye komut gönderilmez. Kümenin kendi içinde çalışan bir GitOps operatörü (ArgoCD veya Flux CD), Git deposunu dışarıya doğru (outbound HTTPS/SSH) okur ve yeni commit'leri içeri çeker. Üretim kümesi dış dünyaya hiçbir yönetim API portu açmak zorunda kalmaz.
• 4. Sürekli Uzlaştırma (Continuously Reconciled): GitOps ajanı 7/24 sonsuz bir kontrol döngüsü (Reconciliation Loop) içinde çalışır. Kümedeki gerçek durumu (Actual State) Git'teki istenen durumla (Desired State) sürekli karşılaştırır. Eğer birisi kümede manuel bir değişiklik yaparsa (Drift), ArgoCD bunu saniyeler içinde tespit eder; OutOfSync uyarısı üretir ve Self-Healing (Kendi Kendini İyileştirme) özelliği aktifse manuel değişikliği otomatik ezerek kümeyi tekrar Git'teki duruma eşitler.

Mimari En İyi Uygulama (App Repo vs. Config Repo Ayrımı): Kurumsal GitOps kurulumlarında uygulama kaynak kodu ile Kubernetes dağıtım manifestoları ayrı Git depolarında tutulur. Uygulama deposunda kod değiştiğinde CI boru hattı yeni Docker imajını (örneğin api-gateway:v2.4.1) üretir ve Container Registry'ye yükler. Ardından CI (veya ArgoCD Image Updater / Flux Image Automation), altyapı/konfigürasyon deposundaki kustomization.yaml veya values.yaml içindeki imaj etiketini güncelleyen otomatik bir commit atar. ArgoCD bu konfigürasyon deposunu izleyerek yeni sürümü canlıya alır. Böylece CI boru hattı sonsuz döngüye girmez ve tek bir git revert komutuyla saniyeler içinde önceki kararlı sürüme dönülebilir.

6. Modern Yazılım Ekosisteminde GitOps ve Progressive Delivery

GitOps yaklaşımı bugün yalnızca arka uç mikroservisleriyle sınırlı değildir. Web3 ve merkezsiz ağ düğümlerinin (validator/RPC nodes) çoklu bulut ortamlarında senkronize edilmesinden, kurumsal şirketlerin düşük kodlu / kodsuz (low-code/no-code) B2B bayi portallarının arka plan entegrasyon servislerinin yönetimine kadar her alanda standartlaşmaktadır.

Ayrıca Argo Rollouts ve Flagger gibi gelişmiş GitOps kontrolcüleri sayesinde Progressive Delivery (Aşamalı Teslimat) süreçleri (Canary, Blue-Green, A/B Testing) de tamamen bildirimsel hale gelmiştir. Örneğin yeni bir sürüm canlıya alındığında Argo Rollouts önce trafiğin yalnızca %5'ini yeni Pod'lara yönlendirir; arka planda Prometheus veya Datadog'a otomatik bir sorgu (AnalysisRun) atarak HTTP 500 hata oranını ve P99 yanıt süresini ölçer. Metrikler sağlıklıysa trafiği %25, %50 ve %100 olarak artırır; eğer hata oranı %1'in üzerine çıkarsa hiçbir mühendisin uyanmasına gerek kalmadan dağıtımı saniyeler içinde otomatik olarak iptal edip (Automated Rollback) trafiği %100 eski kararlı sürüme geri döndürür.

7. Sıkça Sorulan Sorular (SSS)

1. Küçük bir yazılım ekibiyiz (3-5 kişi), hangi Git dallanma stratejisini seçmeliyiz?

Küçük ve çevik ekipler için GitHub Flow veya kısa ömürlü dallarla desteklenen Trunk-Based Development en ideal seçimdir. Git Flow'un getirdiği develop ve release dalları küçük ekiplerde gereksiz birleştirme yükü ve yavaşlama yaratır. Tek bir main dalı kullanmak, her özellik için maksimum 1-2 günlük küçük PR'lar açmak ve otomatik testlerden geçtikten sonra doğrudan canlıya çıkmak teslimat hızınızı maksimuma çıkaracaktır.

2. Git Merge ile Git Rebase arasındaki fark nedir ve PR birleştirirken hangisi kullanılmalıdır?

git merge iki dalın geçmişini birleştirirken yeni bir "merge commit" oluşturur ve dallanma geçmişini olduğu gibi korur; ancak yoğun çalışan ekiplerde Git geçmişinin okunması imkansız bir örümcek ağına (git graph pollution) dönüşmesine neden olur. git rebase ise özellik dalındaki commit'leri alıp main dalının en ucuna sırayla yeniden yazar ve dümdüz (linear) bir geçmiş oluşturur. En iyi pratik olarak; geliştirici kendi yerel dalını güncellerken git pull --rebase kullanmalı, PR'lar main dalına birleştirilirken ise Squash and Merge tercih edilmelidir. Böylece özellik dalındaki 20 küçük deneme commit'i tek, temiz ve Conventional Commits standardına uygun bir commit olarak main dalına eklenir.

3. ArgoCD ile Flux CD arasındaki temel farklar nelerdir?

Her ikisi de CNCF bünyesinde mezun olmuş (Graduated) lider GitOps araçlarıdır. ArgoCD, sunduğu zengin görsel web arayüzü (UI), uygulama topolojisini ve Pod durumlarını canlı şema üzerinde göstermesi, çoklu küme (multi-cluster) yönetimi ve gelişmiş kurumsal RBAC/SSO (Okta, Keycloak, Dex) entegrasyonuyla öne çıkar. Flux CD ise daha modüler, hafif, komut satırı (CLI) ve Kubernetes CRD (Custom Resource Definitions) odaklı bir mimariye sahiptir. Görsel görünürlük isteyen uygulama ekipleri genellikle ArgoCD'yi, tamamen başsız (headless) ve hafif operatör mimarisi arayan altyapı/platform ekipleri ise Flux'ı tercih eder.

4. GitOps kullanırken veritabanı şifresi ve API anahtarı gibi gizli veriler (Secrets) Git'e nasıl konur?

Düz metin (plaintext) Kubernetes Secret dosyaları asla Git deposuna konulmamalıdır (Base64 şifreleme değil, yalnızca kodlamadır!). Bunun yerine iki standart yöntem kullanılır: Birincisi, Bitnami Sealed Secrets veya Mozilla SOPS (KMS/Age) kullanarak gizli verileri asimetrik kriptografi ile şifreleyip Git'e güvenli şekilde koymaktır; şifreyi yalnızca küme içindeki özel anahtara sahip operatör çözebilir. İkincisi ve kurumsal dünyada en yaygın olanı ise External Secrets Operator (ESO) kullanmaktır; Git'te yalnızca şifrenin referans yolu tutulur, ESO ise gerçek şifreyi AWS Secrets Manager, HashiCorp Vault veya GCP Secret Manager'dan çekerek küme içinde Kubernetes Secret nesnesine dönüştürür.

5. Trunk-Based Development yaparken kod incelemesi (Code Review) nasıl yetiştirilir?

Trunk-Based Development, kod incelemesini atlamak anlamına gelmez; aksine inceleme sürecini hızlandırmak demektir. PR'lar 100-200 satırla sınırlandırıldığında bir inceleme 30-45 dakika yerine 5-10 dakika sürer. Ayrıca ekipler Pair Programming (Eşli Programlama) yapıyorsa kod yazılırken anlık olarak iki göz tarafından incelendiği için ek bekleme süresi sıfırlanır. Asenkron çalışmada ise ekip içinde "PR'lar açıldıktan sonra en geç 2 saat içinde incelenir" şeklinde bir mühendislik hizmet seviyesi anlaşması (Team SLA) uygulanır.