Kurumsal DevOps ve CI/CD: GitHub Actions, GitLab, Monorepo ve Deployment Pattern Rehberi

Kurumsal yazılım son beş yılda deploy hızı açısından dönüştü. Yılda 4 release ile çalışan bankalar haftada 2'ye, e-ticaret SaaS'ları günde 5-10'a, modern startup'lar günde 50+'ya çıktı. Bu hız sıçramasının arkasında CI/CD modernizasyonu var — manuel build/test/deploy'dan otomatize pipeline'a, monolith repo'dan monorepo'ya, ssh-deploy'dan GitOps + container orchestration'a. Türkiye'de bu dönüşüm yaklaşık 3 yıl geride; banka + sigorta + telco gibi regülasyonlu sektörler Jenkins-era'da kalırken, e-ticaret + B2B SaaS + AI startup'ları GitHub Actions/GitLab CI'a hızlı geçiyor. KVKK uyumu, BDDK Bilgi Sistemleri Yönetmeliği, ISO 27001 audit — hepsi modern CI/CD pipeline'ından kanıtlanabilir disiplin bekliyor.

Bizim DevOps + CI/CD mühendisliği ve bulut göçü hizmetlerimiz kapsamında son 24 ayda 16 kurumsal CI/CD modernizasyon projesi yürüttük — finans, e-ticaret, sağlık, lojistik, SaaS sektörlerinde. Kendi AIGENCY platformumuzu GitHub Actions + Turborepo + GitOps mimari ile işletiyoruz. Bu yazıda kurumsal DevOps + CI/CD modernizasyonunun yedi pratik kararını sırayla anlatıyoruz: pipeline platform seçimi, repo strateji (monorepo vs polyrepo), build optimizasyonu, test otomasyonu, deployment pattern, secret + secret management, KVKK uyumlu observability.

1. Pipeline platform seçimi — GitHub Actions, GitLab CI, Jenkins karar matrisi

CI/CD platform seçimi iskelet kararıdır — ekip workflow'unu, maliyet yapısını, operasyon yükünü 5+ yıl boyunca belirler.

GitHub Actions:

• Avantaj: GitHub repo ile zero-config entegrasyon, marketplace 15.000+ action, YAML basit, GitHub'ın enterprise pricing'ine dahil. OIDC native (cloud provider IAM ile trust).
• Dezavantaj: action eko sistemi heterojen (her vendor kendi quality, security review yok), self-hosted runner kurulumu (KVKK için) ek emek.
• En uygun: GitHub'da yaşayan kurumlar, modern green-field projeler, küçük-orta ekipler.

GitLab CI/CD:

• Avantaj: GitLab ile tam entegre (issue, merge request, CI, registry, monitoring tek platform), self-hosted versiyon ücretsiz Community Edition, runner self-hosted varsayılan.
• Dezavantaj: GitHub kadar yaygın değil, vendor lock-in (GitLab'a göç ederseniz git history + issue + PR'lar dahil göç).
• En uygun: self-hosted compliance gereksinimi olan kurumsal projeler, KVKK kritik sektörler, all-in-one tek platform isteyenler.

Jenkins:

• Avantaj: 20 yıllık olgunluk, 1.800+ plugin, fully self-hosted, build automation'ın "İsviçre çakısı".
• Dezavantaj: YAML değil Groovy DSL (ekip için ek öğrenme), plugin uyumluluk sorunları, Jenkins-master single point of failure, modern security pratik (OIDC, dynamic secret) ekstra plugin gerektirir.
• En uygun: legacy Java/Maven projeleri, mevcut Jenkins yatırımı olan kurumlar, on-prem zorunluluğu.

CircleCI / Buildkite / Drone CI / Travis CI: niche; Türkiye'de yaygın değil, kurumsal projelerde nadir.

Karar matrisi:

Kriter	GitHub Actions	GitLab CI/CD	Jenkins
Setup süresi	<1 hafta	1-2 hafta	3-6 hafta
Aylık maliyet (orta ekip)	USD 200-1.500	USD 0-1.000 (self-hosted ücretsiz)	Sadece altyapı (~USD 200-1.000)
Self-hosted runner	Mümkün, manuel	Native	Native
OIDC + cloud IAM	Native	Native	Plugin
Plugin / Action ekosistemi	Çok geniş	Geniş	En geniş ama eski
KVKK self-hosted	Runner self-hosted	Tam GitLab self-hosted	Tam self-hosted
Modern UX	Çok iyi	İyi	Eski (Blue Ocean ile iyileşir)

Pratik öneri: yeni proje + GitHub kullanıyor → Actions; on-prem/KVKK kritik → GitLab self-hosted; mevcut Jenkins varsa migration planı 6-12 ay, hemen göç etmeyin.

2. Repo strateji — monorepo vs polyrepo

Repo stratejisi organizasyon yapısını bile etkiler (Conway's law: yazılım organizasyonu yansıtır). Yanlış seçim 1-2 yıl içinde refactor projesi yaratır.

Monorepo (tek repo, çoklu paket):

• Tooling: Nx (TypeScript + node ağırlık), Turborepo (Vercel, modern + hızlı), Bazel (Google, çok-dilli + büyük scale), pnpm workspaces (basit + hafif), Lerna (eski).
• Avantaj: atomic cross-package commit (UI + API + types tek PR'da), ortak deps yönetimi (versiyon mismatch yok), refactoring tüm codebase, kod paylaşımı (utils, types, UI library) zero-friction.
• Dezavantaj: CI karmaşıklığı (sadece etkilenen paketleri build et — affected algoritması), repo boyutu (shallow clone gerek), git operasyon yavaşlar (büyük repo).
• Sweet spot: TypeScript/JS ağırlık, paylaşılan UI/types, 1-3 ekip, 5-15 paket.

Polyrepo (her servis/paket ayrı repo):

• Avantaj: bağımsız deployment cycle, ekip otonomi (her ekip kendi repo kuralı), küçük repo (hızlı clone), blast radius dar (bir servisteki bug başkalarına dokunmaz).
• Dezavantaj: cross-repo change zor (PR koordinasyon), kod tekrarı (utils her repo'ya kopya), versiyon mismatch (paylaşılan SDK 2 farklı versiyon prod'da).
• Sweet spot: bağımsız mikroservis, çoklu dil (Go + Python + Node birarada), 10+ ekip.

Hibrit (orta yol):

• Frontend + paylaşılan paketler tek monorepo, backend mikroservisleri ayrı repo'lar.
• En yaygın enterprise pattern, en az ödün.

Karar matrisi:

Faktör	Monorepo	Polyrepo
Ekip sayısı	1-5	5+
Paket sayısı	5-30	30+ veya 1-3
Dil çeşitliliği	1-2	3+
Cross-package change sıklığı	Yüksek	Düşük
Deploy bağımsızlığı	Düşük (genelde tüm app birlikte deploy)	Yüksek (her servis bağımsız)
Refactoring	Çok kolay	Zor

Pratik öneri: PoC + erken MVP = monorepo (hız + tutarlılık); organizasyon + servis sayısı arttıkça seçici polyrepo'ya kayma. Konservatif: Conway's law'a saygı — organizasyon yapısı kadar paket sınırı çiz.

3. Build optimizasyonu — sadece etkilenen paketler

İyi pipeline'ın single biggest performance lever incremental build. Naive monorepo build'ı her PR'da tüm 15 paketi build eder (12 dk); akıllı incremental sadece etkilenen 2-3'ü (90 saniye).

Build cache pattern:

1. Local cache (developer machine): Turborepo, Nx, Bazel hash-based local cache. İkinci build saniyeler.
2. Remote cache (CI ↔ developer ortak): Turborepo Remote Cache, Nx Cloud, Bazel Build Cache. Developer 1'in build çıktısını CI ve Developer 2 reuse eder. Hashed input → output mapping, S3/Redis backing.
3. Docker layer cache: BuildKit --cache-to type=registry ile docker build cache'i image registry'de tutulur. CI runner ephemeral olsa bile cache hit.

Affected algorithm:

• git diff origin/main...HEAD → değişen dosyalar.
• Dependency graph'ten "etkilenen paketler" (transitive) çıkarılır.
• Sadece bunlar build + test edilir.
• Nx nx affected --target=build, Turborepo turbo run build --filter=...[origin/main], Bazel native.

Pipeline performance pattern:

[git push]
    ↓
[Lint + typecheck affected only] — 60-120s
    ↓
[Unit test affected only] — 90-300s
    ↓ (parallel)
[Build affected only] — 90-300s
[Integration test critical paths] — 5-15min
    ↓
[Deploy staging] — 60-120s
    ↓ (manual approval)
[Deploy production] — 60-180s

Optimize edilmemiş naive pipeline 25-45 dk; optimize edilmiş 5-10 dk. Geliştirici productivity'sinde 3-5× iyileşme.

Pratik hedefler:

• PR pipeline: <10 dk (developer flow korunur)
• Main branch full build: <20 dk
• Production deploy: <5 dk (CI son + actual deploy)

Bu hedefleri sürdürmek CI infrastructure investment + sürekli tuning gerektirir. CI minute maliyeti önemli — orta-büyük ekipte aylık 50K-200K USD GitHub Actions/GitLab CI faturası yaygın, optimize edilince %50-70 düşer.

4. Test otomasyonu — pipeline'ın güven omurgası

Test piramidi (Mike Cohn): %70 unit + %20 integration + %10 e2e. CI'nin verdiği güven her katmanın varlığına + kalitesine bağlı.

Unit test:

• Hız: <50ms/test, paralel execute.
• Coverage hedefi: %70-85 (sektöre göre). Daha yüksek hedef diminishing returns.
• Tooling: Jest, Vitest (modern Node), pytest, Go test, JUnit.
• CI'da: her PR'da, affected paket bazlı.

Integration test:

• Servisler arası gerçek HTTP/gRPC, gerçek DB (test container), gerçek queue.
• Hız: 1-30s/test, sequential veya constrained parallel.
• Hedef: kritik akışlar (auth, payment, core CRUD).
• Tooling: Testcontainers (Docker tabanlı throwaway env), Playwright (API + UI), Pact (contract testing).

End-to-end (e2e) test:

• Browser otomasyonu (Playwright, Cypress), gerçek app deploy edilmiş ortam.
• Hız: 10-60s/test, paralel + flaky riski.
• Hedef: 10-50 critical user journey (login → main task → logout).
• Sıklık: PR'da kritik 5-10 test, nightly full suite.

Flaky test yönetimi:

• CI'da flaky test = güven kaybı + alert fatigue.
• Detection: aynı test 3 koşumdan 2'sinde pass = flaky.
• Quarantine: flaky testler ana suite'ten çıkarılır, ayrı job'da çalışır, hafta sonu fix sprint.
• 0 tolerans: flaky test'lerin kalıcı kalması pipeline kalitesini çürütür.

Security testing CI'da:

• SAST: Semgrep, Snyk Code, GitHub CodeQL (her PR'da).
• SCA (dependency vulnerability): Dependabot, Renovate + Snyk/Trivy (her PR'da).
• DAST: OWASP ZAP, Burp Suite (staging deploy sonrası).
• Container scan: Trivy, Grype (Docker build sonrası).
• IaC scan: Checkov, tfsec (Terraform PR'da).

Pipeline test coverage matrix:

Stage	Hangi testler
PR open	Lint + typecheck + unit + SAST + dependency scan
PR merge to main	+ integration + container scan + e2e smoke
Staging deploy	+ full e2e + DAST + performance test
Production deploy	+ post-deploy smoke + monitoring sync

5. Deployment pattern — rolling, blue-green, canary

Deploy pattern'i risk toleransı + sektör + bütçeye göre seçilir.

Rolling deployment:

• N instance'ı 2-N adımda yeniden başlat (örnek: 10 instance → 2'şer 2'şer güncelle, 5 adım).
• Kubernetes default (RollingUpdate strategy).
• Avantaj: zero ek altyapı, basit, çoğu PaaS otomatik.
• Dezavantaj: rollback yavaş (geri rollout), eski + yeni aynı anda live → DB schema breaking change problemli.
• Sweet spot: stateless servis, küçük-orta ekip, KOBİ.

Blue-green deployment:

• İki tam paralel ortam: blue (current prod) + green (new). DNS/LB switch ile geç.
• Zero-downtime, instant rollback (DNS geri).
• Avantaj: production-identical test (green'i prod-fashion test eder), incident'ta saniyelik rollback.
• Dezavantaj: 2× altyapı maliyeti, DB tek (paralelleşmez — schema migration backwards-compatible olmalı).
• Sweet spot: B2B SaaS, regülasyonlu sektör, finansal işlem.

Canary deployment:

• Yeni versiyon trafik dağılımı: %1 → %5 → %25 → %50 → %100. Her aşamada metric (error rate, latency, business KPI) izlenir.
• Otomatik rollback: error rate threshold aşılırsa eski versiyona dön.
• Avantaj: gerçek production trafiğinde validasyon, en güvenli, A/B testing zaten varsa "ücretsiz".
• Dezavantaj: feature flag sistemi gerekli (LaunchDarkly, Unleash, custom), observability mature olmalı, karmaşık.
• Sweet spot: yüksek-volume tüketici (e-ticaret, sosyal medya), milyon+ kullanıcı.

Modern hybrid: Argo Rollouts, Flagger, Spinnaker — Kubernetes-native canary + blue-green orchestration. Service mesh (Istio, Linkerd) ile trafik bölme + observability integration.

GitOps (Argo CD, Flux):

• Deploy state Git repo'da declarative (Helm charts, Kustomize manifests).
• Production = Git'in projection'u. Manual kubectl apply yok.
• Otomatik drift detection + reconciliation (cluster Git'ten farklıysa cluster düzeltilir).
• Audit trail: kim ne zaman ne deploy etti → Git commit history.
• KVKK + compliance perspektifinden ideal: değişiklik kanıtı immutable.

Pratik karar matrisi:

Sektör / Senaryo	Önerilen
KOBİ web/app, <50K kullanıcı	Rolling
Orta B2B SaaS, 50K-500K	Blue-green
E-ticaret, finans, >500K	Canary + GitOps
Bankacılık core	Blue-green + Canary hybrid + extensive manual approval
Mikroservis ağı, >20 servis	GitOps + Argo Rollouts

6. Secret + artifact management — pipeline'ın güvenlik kapısı

CI/CD pipeline kimlik bilgilerinin (DB password, cloud IAM key, API token, SSL cert) merkezi noktası. Yanlış yönetim = breach kaynağı.

Secret management pattern stack:

[Developer]
    ↓ (commit code, NO secrets in repo)
[Git repo] — .gitignore .env, pre-commit secret scan (git-secrets, truffleHog)
    ↓
[CI runner]
    ↓ (fetch at runtime)
[Secret store: Vault / Secrets Manager / Key Vault]
    ↓ (short-lived token via OIDC)
[Application]

Layer 1 — Repo discipline:

• .env .gitignore, git secrets --register-aws global hook.
• Pre-commit: husky + lint-staged + secret pattern scan.
• Repo history scan (BFG, git-filter-repo) — geçmişte sızmış secret varsa rotate.

Layer 2 — CI native secret store:

• GitHub Actions: Settings → Secrets and variables → Actions. Masked output, environment-scoped, branch-protected.
• GitLab: Settings → CI/CD → Variables. Protected, masked, expand variables.
• Jenkins: Credentials Plugin + folder-level scoping.
• Her access audit log'lanır.

Layer 3 — External secret manager:

• HashiCorp Vault: self-hosted, en yaygın enterprise, dynamic secret üretme (DB credential pipeline çağırınca yaratılır + 1 saat TTL).
• AWS Secrets Manager / Azure Key Vault / GCP Secret Manager: cloud-native, vendor lock-in.
• Doppler, 1Password Secrets Automation: SaaS modern alternatif.
• KVKK kritik kurumlar için Vault zorunlu (data residency + audit log + access control matrix).

Layer 4 — OIDC trust (short-lived credentials):

• GitHub Actions ↔ AWS IAM Role: GitHub identity token → AWS STS AssumeRole → 15dk geçici credential.
• Statik IAM access key gereksiz — bir credential leak ihtimali sıfıra iner.
• Setup: GitHub Actions workflow + AWS IAM OIDC provider + Role trust policy.

Layer 5 — Audit + rotation:

• Her secret access log'lanır (CloudTrail, Vault audit log, GitLab audit events).
• 90 günlük otomatik rotation policy.
• Kullanılmayan secret 30 gün sonra revoke.
• Quarterly access review (kim hangi secret'a hâlâ ihtiyaç duyuyor).

Artifact management:

• Docker image: GitHub Container Registry (ghcr.io), Docker Hub, AWS ECR, Harbor (self-hosted).
• Build artifact (jar, npm pkg): GitHub Packages, JFrog Artifactory, Nexus (self-hosted).
• Retention policy: prod tag'leri sınırsız, PR build'leri 30 gün, scheduled prune.
• Signing: Sigstore Cosign, Notary v2 — supply chain integrity (image gerçekten bizim CI'dan mı geldi?).

Bizim SOC operasyon yazımız CI/CD pipeline log'larının SOC SIEM'e nasıl entegre edileceğini detaylandırır.

7. KVKK uyumlu observability + audit

CI/CD pipeline kişisel veri işlemez gibi görünür ama dolaylı olarak: developer kimliği (commit author), deploy kararı (who approved), pipeline log içinde test data (mock customer email), production access (debug session). KVKK + ISO 27001 audit'leri için yazılı disiplin gerekir.

Yedi disiplin:

1. Pipeline run log immutable: GitHub Actions / GitLab CI run history (var, 90 gün default, enterprise plan'da 400 gün). KVKK audit için 12 ay + retention politikası yazılı.

2. Developer kimlik (commit) policy: Verified commits (GPG/SSH signed) zorunlu, anonymous commit yok. Bu kanıt: kim ne yazdı, kim merge etti.

3. Approval gates audit'lenir: production deploy için 2 reviewer (GitHub branch protection rule), her approval log'da kim + ne zaman + commit SHA.

4. Test data sanitization: test fixtures'ta gerçek customer email/TC/IBAN yok. Faker library + synthetic data. CI log'da PII görünmemeli.

5. Production debug log access: pipeline'dan production'a debug session sınırlı (break-glass procedure), her access log'lanır + post-hoc justification.

6. Secret access audit: hangi pipeline run hangi secret'ı çağırdı → Vault audit log + correlation pipeline run ID ile.

7. Compliance reporting: aylık report — kaç deploy, kaç rollback, kaç hotfix, kaç incident. KVKK risk assessment'ine girer.

Observability stack:

• Pipeline metrics: DORA metrics (deploy frequency, lead time, change failure rate, MTTR) — DevOps state-of-art KPI. Tracker: LinearB, Sleuth, DX Engineering Effectiveness.
• Build performance: cache hit rate, average pipeline duration, queue time, runner utilization.
• Cost tracking: GitHub Actions usage report, GitLab CI minute analytics, cloud runner spot pricing.
• Failure analytics: flaky test detection, infrastructure failure vs code failure ayrımı.

DORA metrics target (DORA Elite tier):

• Deploy frequency: günlük 1+
• Lead time for changes: <1 saat (commit → prod)
• Change failure rate: <%15
• MTTR (failed change recovery): <1 saat

Bu hedeflere ulaşmak yıllar sürer; kurumsal ortalama (Medium tier): haftada 1-7 deploy, <1 gün lead time, %15-30 failure rate, <1 gün MTTR.

Pratik özet — başlangıç check-list'i

İlk üretim CI/CD modernizasyonu projeniz için doğru sıra:

1. Platform seçimi: GitHub repo → Actions; on-prem/KVKK → GitLab self-hosted; legacy → Jenkins migration plan.
2. Repo strateji: 1-3 ekip + JS/TS = monorepo (Turborepo/Nx); 5+ ekip + çoklu dil = polyrepo; hibrit en yaygın.
3. Build optimizasyonu: affected algorithm + remote cache + Docker layer cache. PR pipeline <10 dk hedef.
4. Test piramidi: %70 unit + %20 integration + %10 e2e; flaky 0 tolerans; SAST + SCA + DAST + IaC scan CI'da.
5. Deployment pattern: KOBİ rolling; orta B2B blue-green; high-volume canary; GitOps (Argo CD) compliance için ideal.
6. Secret management: Vault veya cloud manager + OIDC short-lived credentials + audit + 90 gün rotation.
7. Artifact management: image registry + signing (Cosign) + retention policy.
8. KVKK observability: pipeline log 12 ay retention, verified commits, audit'li approval gates, test data sanitization.
9. DORA metrics: deploy frequency / lead time / failure rate / MTTR — aylık dashboard.
10. Sürekli iyileştirme: quarterly platform retro, CI cost optimization, security training, runbook güncellemesi.

Bu liste minimum disiplin. Üzerine sektörel ek (PSD2 için payment service deploy kontrol, FDA için medical device validation pipeline, ISO 27001 için change management evidence) eklenir. CI/CD'nin değeri kurulu olmakta değil, DORA metrics'in haftalık ölçülebilir iyileşmesinde — deploy hızı + güveni + recoverability'nin sayısal trend grafiği.

Bizim ekibimiz Şanlıurfa Karaköprü'den DevOps + CI/CD mühendisliği ve bulut göçü hizmetleriyle finans, e-ticaret, sağlık, lojistik sektörlerinde CI/CD modernizasyon projeleri yürüttü ve kendi AIGENCY platformumuzu GitHub Actions + Turborepo + GitOps mimari ile işletiyor. Kurumsal CI/CD modernizasyon pilotu, mevcut pipeline'ınızın DORA metric audit'i veya monorepo/polyrepo karar danışmanlığı için iletişim formundan ulaşabilirsiniz — ilk değerlendirme görüşmesi ücretsizdir.

---

eCloud Tech — Şanlıurfa merkezli kurumsal yazılım, yapay zekâ, blockchain ve siber güvenlik ekibi. Building Tomorrow.