- 01CI/CD, kod değişikliklerini sık entegre etmek, otomatik doğrulamak ve güvenilir biçimde release/deploy edilebilir hale getirmek için kullanılan yazılım teslim yaklaşımıdır.
- 02Continuous Delivery production'a hazır artifact üretir ancak manuel approval içerebilir; Continuous Deployment gerekli kontrolleri geçen değişiklikleri otomatik olarak production'a gönderir.
- 03Sağlıklı pipeline yalnız deploy etmez; build, test, quality/security checks, artifact, deployment ve post-deploy verification adımlarını kapsar.
- 04CI/CD Kubernetes'e bağlı değildir; VM, bare metal, container host, serverless veya managed platformlara deployment yapabilir.
- 05Pipeline performansı build süresinin yanında change lead time, deployment frequency ve change fail rate gibi delivery metrikleriyle birlikte değerlendirilmelidir.
Kısaca
CI/CD, yazılım değişikliklerini daha sık entegre etmek, otomatik test etmek ve kontrollü biçimde release/deploy edilebilir hale getirmek için kullanılan teslim yaklaşımıdır. CI, kod değişikliklerinin sürekli entegrasyonuna ve doğrulanmasına; CD ise yazılımın güvenilir biçimde teslim veya deploy edilmesine odaklanır. Dynamis Teknoloji, CI/CD'yi yalnız bir pipeline dosyası değil; build, test, artifact, güvenlik kontrolü, deployment ve production doğrulamasından oluşan uçtan uca teslim süreci olarak ele alır.
CI/CD nedir?
CI/CD iki temel yaklaşımı birleştirir:
- Continuous Integration
- Continuous Delivery veya Continuous Deployment
Bu akışın amacı, kod değişikliklerini büyük release'ler halinde biriktirmek yerine daha küçük parçalarla doğrulamak ve production'a taşımaktır.
Basit akış:
Kod değişikliği → build → test → artifact → deploy → doğrulama
İyi tasarlanmış bir CI/CD pipeline manuel adımları azaltır, hatayı daha erken yakalar ve deployment sürecini tekrarlanabilir hale getirir.
Continuous Integration nedir?
Continuous Integration, geliştiricilerin kod değişikliklerini sık aralıklarla ortak repository'ye entegre etmesi ve her değişikliğin otomatik kontrollerden geçmesi yaklaşımıdır.
Tipik CI aşamaları:
- Commit veya pull request tetiklenir
- Dependency'ler yüklenir
- Build alınır
- Unit test çalışır
- Lint/static analysis çalışır
- Security scan uygulanabilir
- Artifact üretilir
Amaç integration problemlerini release gününde değil, değişikliğe yakın zamanda bulmaktır.
Continuous Delivery nedir?
Continuous Delivery, testlerden geçen yazılımın her an production'a çıkabilecek durumda tutulmasıdır.
Burada production deployment otomatik olmak zorunda değildir.
Örneğin:
- CI başarılı
- staging deploy edildi
- integration test geçti
- artifact production için hazır
- son production geçişi manuel approval ile yapılıyor
Bu model Continuous Delivery'dir.
Continuous Deployment nedir?
Continuous Deployment, gerekli otomatik kontrollerden geçen değişikliklerin manuel release adımı olmadan production'a gönderilmesidir.
Bu modelde pipeline:
- test
- security policy
- deployment
- smoke test
aşamalarını otomatik yürütür.
Her şirket continuous deployment kullanmak zorunda değildir.
Finans, sağlık veya yüksek riskli production ortamlarında kontrollü manuel approval noktaları gerekli olabilir.
CI/CD pipeline nedir?
Pipeline, yazılım değişikliğinin source code'dan production'a kadar geçtiği otomatik aşamalar zinciridir.
Örnek pipeline:
| Aşama | Amaç |
|---|---|
| Source | Değişikliği tetiklemek |
| Build | Uygulamayı paketlemek |
| Test | Fonksiyonel hatayı erken yakalamak |
| Quality | Lint/static analysis |
| Security | Dependency, secret veya image scan |
| Artifact | Tekrarlanabilir release çıktısı üretmek |
| Deploy | Hedef ortama göndermek |
| Verify | Smoke/health test yapmak |
Pipeline uygulamaya göre daha basit veya daha karmaşık olabilir.
Pipeline'ın amacı sadece deploy etmek değildir
Yaygın hata CI/CD'yi yalnız "server'a kod gönderme" olarak görmektir.
Asıl amaç:
- değişiklik kalitesini doğrulamak
- manuel hatayı azaltmak
- tekrar üretilebilir release oluşturmak
- deployment geçmişini izlemek
- rollback'i kolaylaştırmak
- feedback süresini kısaltmak
olmalıdır.
Bir rsync veya SSH script'i deployment automation olabilir; ancak tek başına sağlıklı CI/CD pipeline değildir.
Artifact neden önemlidir?
Build çıktısının tek ve değişmez artifact olarak üretilmesi, staging ile production arasında farklı binary/package kullanılmasını önler.
Örnek artifact:
- Docker image
- JAR
- .NET package
- Node.js build
- Helm chart
- VM image
İyi modelde aynı artifact farklı environment'lara promote edilir.
Bu yaklaşım "staging'de çalışan kod production'da neden farklı?" problemini azaltır.
Environment farklarını nasıl yönetmelisiniz?
Kod aynı kalmalı, environment configuration ayrışmalıdır.
Örneğin:
- database URL
- API key
- feature flag
- secret
- external endpoint
environment bazında yönetilebilir.
Bunları source code içine hard-code etmek yerine secret/configuration katmanında tutun.
CI/CD ve secret management
Pipeline'lar production credential'larına erişebildiği için güvenlik açısından kritik sistemlerdir.
Kaçının:
- secret'ı repository'ye yazmak
- uzun ömürlü root credential kullanmak
- herkesin production deploy edebilmesi
- pipeline loglarında secret göstermek
Tercih edin:
- short-lived credential
- environment scoped secret
- least privilege
- protected branch
- approval rule
- audit log
Branch strategy pipeline'ı etkiler
Tek bir doğru branch modeli yoktur.
Örnekler:
- trunk-based development
- short-lived feature branch
- GitFlow
DORA araştırmaları küçük batch'leri ve sık entegrasyonu destekler.
Uzun yaşayan branch'ler integration riskini artırabilir.
Bu nedenle branch modelini release akışınız ve ekip büyüklüğünüzle uyumlu seçin.
Pull request pipeline'ı nasıl olmalı?
Pull request aşamasında hızlı kontroller çalışmalıdır.
Örnek:
- build
- unit test
- lint
- static analysis
- secret scan
Amaç geliştiriciye dakikalar içinde feedback vermektir.
30-40 dakika süren tüm testleri her küçük değişiklikte zorunlu çalıştırmak developer feedback loop'u yavaşlatabilir.
Testleri risk seviyesine göre katmanlayın.
Staging gerekli mi?
Her proje için zorunlu değildir.
Staging şu durumlarda değerlidir:
- integration dependency fazlaysa
- production benzeri environment gerekiyorsa
- database migration test edilecekse
- business acceptance gerekiyorsa
- release riski yüksekse
Ancak staging production'dan çok farklıysa yanlış güven hissi yaratabilir.
Database migration CI/CD içinde nasıl yönetilir?
Database değişiklikleri deployment'ın en riskli parçalarından biridir.
Tercih edilen yaklaşım:
- backward-compatible schema değişikliği
- migration script version control
- backup/rollback planı
- migration öncesi validation
- uygulama ve schema uyumluluğu
Örneğin önce yeni column eklemek, uygulamayı geçirmek ve eski column'u daha sonra kaldırmak daha güvenli olabilir.
Tek adımda destructive schema değişikliği rollback'i zorlaştırabilir.
Deployment stratejileri
Rolling deployment
Instance'lar kademeli güncellenir.
Avantaj:
- düşük ek kapasite ihtiyacı
Risk:
- eski ve yeni sürüm bir süre birlikte çalışır
Blue-green
Eski ve yeni environment paralel tutulur.
Avantaj:
- hızlı rollback
Risk:
- daha fazla altyapı maliyeti
Canary
Trafiğin küçük yüzdesi yeni sürüme yönlendirilir.
Avantaj:
- production riskini sınırlı kullanıcı grubunda gözlemleme
Risk:
- routing ve observability daha karmaşıktır
Deployment stratejisi uygulama riskine göre seçilmelidir.
CI/CD pipeline'da rollback nasıl tasarlanır?
Rollback pipeline sonradan eklenen bir script olmamalıdır.
Önceden belirleyin:
- hangi metrik rollback tetikler
- önceki artifact nerede
- database backward-compatible mı
- config geri alınabiliyor mu
- trafik nasıl dönecek
Deployment sonrası error rate veya latency belirli sınırı aşarsa otomatik veya yarı otomatik rollback uygulanabilir.
Deployment sonrası doğrulama
Pipeline "deploy successful" dediğinde iş bitmez.
Kontrol edin:
- health endpoint
- error rate
- latency
- critical user flow
- database connection
- queue/worker health
- external integration
Smoke test production doğrulamasının ilk katmanıdır.
CI/CD için Kubernetes gerekli mi?
Hayır.
CI/CD şu hedeflere deploy edebilir:
- VM
- bare metal
- Docker host
- Kubernetes
- serverless
- managed app platform
Kubernetes yalnız deployment hedeflerinden biridir.
DevOps nedir? rehberinde de belirttiğimiz gibi DevOps ve CI/CD, Kubernetes'ten bağımsız uygulanabilir.
GitHub Actions, GitLab CI veya Jenkins hangisi?
Araç seçimi pipeline tasarımından sonra gelmelidir.
GitHub Actions
Repository GitHub'daysa güçlü entegrasyon ve hızlı başlangıç sunar.
GitLab CI/CD
GitLab repository, registry ve deployment akışını tek platformda tutmak isteyen ekipler için uygundur.
Jenkins
Çok esnek ve uzun yıllardır kullanılan platformdur; ancak self-hosted Jenkins operasyon ve plugin yönetimi gerektirir.
Araç seçiminde:
- repository platformu
- self-hosted ihtiyacı
- runner modeli
- secret yönetimi
- compliance
- ekip deneyimi
değerlendirilmelidir.
Pipeline performansı nasıl ölçülür?
Pipeline seviyesinde:
- build süresi
- test süresi
- failure rate
- queue time
- flaky test oranı
izlenebilir.
Delivery seviyesinde DORA metrikleri kullanabilirsiniz:
- change lead time
- deployment frequency
- failed deployment recovery time
- change fail rate
- deployment rework rate
Amaç yalnız pipeline süresini kısaltmak değil, toplam teslim sürecini iyileştirmektir.
Pipeline çok yavaşsa ne yapılmalı?
Önce darboğazı ölçün.
Yaygın nedenler:
- dependency her seferinde yeniden indiriliyor
- cache yok
- testler seri çalışıyor
- container image gereksiz büyük
- runner kapasitesi düşük
- integration test kapsamı yanlış aşamada
İyileştirmeler:
- dependency cache
- parallel test
- incremental build
- küçük Docker image
- autoscaling runner
- test katmanlama
olabilir.
CI/CD güvenlik kontrolünü nereye koymalı?
Her kontrol aynı aşamada çalışmak zorunda değildir.
Örnek:
Commit/PR:
- secret scan
- lint
- unit test
- static analysis
Build:
- dependency scan
- image scan
Pre-production:
- integration test
- policy check
Production:
- approval
- runtime validation
- post-deploy monitoring
Amaç güvenliği son release gate'e yığmak değil, erken feedback sağlamaktır.
Küçük ekip için minimum pipeline
5-20 kişilik ekip için ilk pipeline şöyle olabilir:
- Pull request açılır
- Build çalışır
- Unit test çalışır
- Main'e merge edilir
- Artifact/container image oluşturulur
- Staging otomatik deploy edilir
- Smoke test çalışır
- Production manuel approval ile deploy edilir
- Health check doğrulanır
Bu model karmaşık olmadan tekrarlanabilir deployment sağlar.
CI/CD projesine nereden başlanmalı?
Adım 1: Mevcut deployment sürecini yazın
Kim, hangi komutlarla, hangi erişimle deploy ediyor?
Adım 2: Tekrarlanan manuel adımları bulun
Her release'te yapılan işleri listeleyin.
Adım 3: Build'i tekrarlanabilir hale getirin
Geliştirici laptop'una bağlı build sürecini kaldırın.
Adım 4: Testleri pipeline'a taşıyın
Önce hızlı ve kritik testlerle başlayın.
Adım 5: Artifact standardı kurun
Her release için versiyonlanmış artifact üretin.
Adım 6: Staging/deployment otomasyonu kurun
Hedef ortama tekrar üretilebilir deployment sağlayın.
Adım 7: Production gate belirleyin
Risk seviyesine göre manuel veya otomatik karar verin.
Adım 8: Deployment sonrası gözlemleyin
Monitoring ve rollback mekanizmasını bağlayın.
Dynamis'te CI/CD yaklaşımı
Dynamis'in DevOps hizmeti kapsamında CI/CD çalışmasına yalnız YAML dosyası yazarak başlamıyoruz.
Önce:
- repository
- branch modeli
- mevcut deployment
- test kapsamı
- environment'lar
- artifact modeli
- secret yönetimi
- production access
- rollback
- monitoring
incelenir.
Sonra ihtiyaca göre:
- GitHub Actions
- GitLab CI/CD
- Jenkins
- container registry
- Infrastructure as Code
- Kubernetes deployment
- VM deployment
gibi bileşenler seçilir.
Amaç aracı standardize etmek değil, release sürecini tekrarlanabilir ve ölçülebilir hale getirmektir.
Sık yapılan hatalar
CI/CD = deploy script demek: Test, artifact ve doğrulama eksik kalır.
Continuous Delivery ile Deployment'ı aynı sanmak: Production'a otomatik çıkış farklı bir karardır.
Secret'ları repository'ye koymak: Pipeline güvenlik riskine dönüşür.
Rollback düşünmeden otomasyon yapmak: Hızlı deployment, hızlı recovery olmadan eksik kalır.
Her testin her commit'te çalışması: Feedback loop gereksiz yavaşlayabilir.
Pipeline aracını strateji sanmak: GitHub Actions veya Jenkins seçmek tek başına CI/CD tasarımı değildir.
Sırada ne var
- Infrastructure as Code nedir? Cloud altyapısı kodla nasıl yönetilir?: application pipeline'ına infrastructure plan, review ve kontrollü apply sürecini ekleyin.
- Observability nedir? Monitoring, logging ve tracing farkları: deployment sonrası metrics, logs ve traces ile release etkisini ölçün ve rollback sinyallerini tanımlayın.
- DevOps nedir?: CI/CD'nin daha geniş DevOps çalışma modelindeki yerini görün.
- Kubernetes'e geçiş rehberi: Kubernetes deployment hedefi kullanacaksanız production geçişini planlayın.
- Kubernetes nedir? Ne işe yarar ve ne zaman kullanılmalı?: Kubernetes deployment hedefini seçmeden önce temel mimariyi ve operasyon sorumluluklarını öğrenin.
- Küçük ekip için Kubernetes: Kubernetes'in gerçekten gerekli olup olmadığını değerlendirin.
- DevOps hizmeti: CI/CD ve deployment otomasyon sürecinizi değerlendirin.
Kaynaklar
Kaynaklar
- 1.Continuous integration solutionsGoogle Cloud · 2026-09-21
- 2.Continuous integration with GitHub ActionsGitHub Docs · 2026-09-21
- 3.CI/CD pipelinesGitLab Docs · 2026-09-21
- 4.Software delivery performance metricsDORA · 2026-09-21
Sık sorulan sorular
CI/CD nedir?
CI/CD, kod değişikliklerini sürekli entegre etmek, otomatik test etmek ve güvenilir biçimde release/deploy edilebilir hale getirmek için kullanılan yazılım teslim yaklaşımıdır. CI entegrasyon ve doğrulamaya, CD ise teslim veya deployment otomasyonuna odaklanır.
Continuous Delivery ile Continuous Deployment arasındaki fark nedir?
Continuous Delivery, yazılımı her an production'a çıkabilecek durumda tutar ancak production release'i manuel onay içerebilir. Continuous Deployment ise gerekli kontrolleri geçen değişiklikleri otomatik olarak production'a gönderir.
CI/CD pipeline hangi aşamalardan oluşur?
Basit bir pipeline genellikle source/trigger, build, automated test, security veya quality checks, artifact üretimi, deployment ve deployment sonrası doğrulama aşamalarından oluşur. Gerçek akış uygulama ve risk modeline göre değişir.
CI/CD için Kubernetes gerekli mi?
Hayır. CI/CD VM, bare metal, container platformu, serverless veya Kubernetes üzerinde uygulanabilir. Kubernetes deployment hedeflerinden biri olabilir; CI/CD yaklaşımının kendisi Kubernetes'e bağlı değildir.
CI/CD pipeline kurarken hangi metrikler izlenmeli?
Pipeline süresi, başarısız build/test oranı, deployment frequency, change lead time, failed deployment recovery time ve change fail rate gibi ölçüler kullanılabilir. Amaç yalnız pipeline'ı hızlandırmak değil, teslim sürecindeki bekleme ve hata noktalarını azaltmaktır.