CI/CD aracı değişir; dersler değişmez
Her ekibin CI'yi bir araçtan diğerine taşıma hikâyesi vardır, aynı problemler bir yıl içinde yeni araçta ortaya çıkar.Araç karşılaştırması
- GitHub Actions — kod GitHub'daysa varsayılan. Marketplace geniş. YAML makul. Küçük-orta ekipler için makul ölçeklenir.
- GitLab CI — GitLab ile sıkı entegre. GitLab platformsa sağlam seçim.
- Jenkins — legacy varsayılan. Sonsuz esneklik plugin'lerle, karşılığında sonsuz plugin bakımı.
- Buildkite, CircleCI, Drone, Argo, Tekton — her birinin nişi var.
2026'da sıfırdan başlayan çoğu ekip için GitHub Actions en az direnç yolu.
Tutan pipeline yapısı
Çalışan bir pipeline minimum yapar:- Compile / artefact build.
- Unit testler.
- Linter / static analiz.
- Container image build.
- Integration testler.
- Güvenlik taramaları (SAST, dependency, image).
- Testler geçtiğinde artefact tag ve publish.
- Main branch'te staging'e otomatik deploy.
- Manuel approval gate ile production deploy.
Sıra önemli. Hızlı checkleri (lint) pahalı yavaş checkler (integration) öncesi. Fail fast.
Kardinal günah: çok saatlik pipeline
Geliştiriciye 45 dakikada feedback veren pipeline kaçınılan pipeline'dır. Hedeflerimiz:- Compile + lint + unit testler: tek PR için 5 dakika altı.
- Tam pipeline: 20 dakika altı.
Caching: en yüksek kaldıraçlı optimizasyon
- Bağımlılık cache'leri (npm, pip, go mod, cargo, maven).
- Docker BuildKit cache.
- Test sonuç caching.
Pipeline'larda secret'lar
- Environment variable'larda secret'lar — job'a scope edildiyse iyi.
- Fork'lardan PR run'larında secret'lar — sıkı scope edin.
- Uzun ömürlü statik kimlik bilgileri — OIDC tabanlı federation ile değiştirin.
- Secret rotation — otomatikleştirin.
Branch / deployment / environment koruması
- Main branch PR + review + yeşil CI gerektirir.
- Production environment manuel approval gerektirir.
- Rollback yolu — her deploy'un test edilmiş rollback'i olmalı.
Pipeline observability
İzleyin:- Pipeline süresi.
- Pipeline başarısızlık oranı.
- Flaky test oranı.
- Bozuk main'i düzeltme ortalama süresi.
Uyaracağımız bir desen
Soyutlama olmadan dev pipeline dosyalarıyla yapılandırma. Reusable templates / composite actions kullanın.Her zaman karşılığını veren bir desen
Uygulama kodundan ayrı "pipeline-as-code" repo.CI aracınız nedir?
The CI/CD tool changes; the lessons don't
Every team has a story about migrating CI from one tool to another, with the same problems showing up on the new tool within a year.The tool comparison
- GitHub Actions — the default if your code is on GitHub.
- GitLab CI — tightly integrated with GitLab.
- Jenkins — the legacy default. Endless flexibility via plugins.
- Buildkite, CircleCI, Drone, Argo, Tekton — each has a niche.
The pipeline structure that holds
A working pipeline does:- Compile / build the artefact.
- Run unit tests.
- Run linters / static analysis.
- Build the container image.
- Run integration tests.
- Run security scans (SAST, dependency, image).
- Tag and publish the artefact.
- Deploy to staging automatically on main branch.
- Deploy to production via a manual approval gate.
The cardinal sin: a multi-hour pipeline
Targets:- Compile + lint + unit tests: under 5 minutes per PR.
- Full pipeline: under 20 minutes.
Caching: the highest-leverage optimisation
- Dependency caches.
- Docker BuildKit cache.
- Test result caching.
Secrets in pipelines
- Secrets in environment variables — fine if scoped.
- Secrets in PR runs from forks — scope tightly.
- Long-lived static credentials — replace with OIDC.
- Secret rotation — automate it.
Branch / deployment / environment protection
- Main branch requires PR + review + green CI.
- Production environment requires manual approval.
- Rollback path — every deploy must have a tested rollback.
Pipeline observability
Track:- Pipeline duration.
- Pipeline failure rate.
- Flaky test rate.
- Mean time to fix a broken main.
One pattern we'd warn about
Configuration via giant pipeline files with no abstraction.One pattern that always pays off
A "pipelines as code" repo separate from application code.What's your CI tool?
