CI/CD Pipeline Kurulumu ve Otomasyon: DevOps Rehberi [2026]

CI/CD: Yazılım Geliştirme Hızını Dönüştürmek

Yazılım geliştirme, geçmişte aylar alan dağıtım döngüsü ile başarısız olmuş. Geliştirici bir özellik yazardı, ayrı bir test ekibi onun denetini yapardı, operasyon ekibi kurumsal sunuculara dağıtırdı. Bu süreçte haftalar geçerdi. Bugün başarılı kuruluşlar, değişiklikleri saatlerce belki dakikalarca canlı ortama gönderiyor.

CI/CD, bu hızlandırmanın altyapısıdır. CI (Continuous Integration) sayesinde, kod değişiklikleri otomatik test edilir. CD (Continuous Deployment) sayesinde, test geçen kod otomatik canlı ortama gider. Sonuç: hata oranı azalır, kullanıcılara yeni özellikler hızlı ulaşır, yazılım ekibi sanalık için daha az zaman kaybeder.

CI/CD Pipeline Nedir?

Bir pipeline, yazılım kodunun geliştiricinin bilgisayarından başlayarak, canlı ortamdaki kullanıcılara kadar geçtiği otomatik sürece denir.

Aşamaları:

Kod depolan (commit): Geliştirici kodunu Git deposuna gönderir. Bu otomatik olarak pipelineyi tetikler.

Derleme (build): Kod, uygulamaya dönüştürülür. Derleme hatası varsa pipeline durur, geliştirici uyarı alır.

Otomatik testler: Birim testleri, entegrasyon testleri, güvenlik testleri çalıştırılır. Herhangi bir test başarısız olursa, kod canlıya gitmez.

Staging ortamına dağıtım: Canlıya gitmeden önce, aynı ortamda son kez test edilir.

Canlı ortama dağıtım: Tests başarılı ve onay varsa, kod kullanıcılara sunulur.

Monitoring: Canlı ortamda sorun çıkarsa, otomatik geri alma (rollback) yapılır.

Sürekli Entegrasyon (CI) Faydaları

Hata Erken Tespiti: Geliştirici kod yazar yazılamaz, hatalar bulunur. Haftalar sonra bulunmaktan çok daha iyidir.

Entegrasyon Sorunlarını Giderir: 20 geliştirici kod yazıyorsa, bunların bir arada çalışması emin değildir. CI, tüm kodun uyumunu kontrol eder.

Düşük Riskli Değişiklikler: Küçük, sık değişiklikler yapılabilir. Büyük, ay sürüp başarısız olan değişikliklerden kurtulabilirsiniz.

Kalite Standartları Otomatik Kontrol: Kod tarzı, karmaşıklık, güvenlik sorunları, otomatik aletler ile tespit edilir. İnsan gözlemleri olmasa bile, minimum standart sağlanır.

Sürekli Dağıtım (CD) Faydaları

Daha Hızlı Pazara Erişim: Rekabet avantajı, yeni özellikte değildir, hızda yatmaktadır. Şampiyonlar, günde 10 defa dağıtım yapabilir.

Kullanıcı Geri Bildirimini Hızlı Almak: Özellik canlıya gidince, gerçek kullanıcılardan geri bildirim alırsınız. Tasarım ve geliştirme ekibini iyileştirmek için ihtiyaç duydukları veriyi hızlı elde edersiniz.

Sorunlara Hızlı Cevap: Güvenlik açığı bulunsa, kodda bug çıksa, hızlı düzeltme dağıtabilirsiniz.

Daha Güvenilir Dağıtımlar: Her dağıtım otomatik, aynı adımları izler. İnsan hatası neredeyse ortadan kalkar.

CI/CD Pipeline Araçları Karşılaştırması

GitHub Actions

GitHub üzerinde kod barındırıyorsanız, Actions doğal seçimdir. YAML dosyası ile workflow tanımlarsınız.

Avantaj: GitHub ile entegre, kurulum kolay, aylık bin dakika ücretsiz.

Dezavantaj: Karmaşık pipelinelerde, diğer araçlardan daha sınırlı olabilir.

Aylık maliyet (500 dakika): 0 ila 30 dolar arası.

GitLab CI/CD

GitLab'ın dahili CI/CD sistemi. GitLab Server'da kendi sunucularında çalıştırabileceğiniz gibi, GitLab.com üzerinde de kullanabilirsiniz.

Avantaj: Çok güçlü, esnek, GitLab alt yapısında tam kontrol.

Dezavantaj: Daha karmaşık kurulum, öğrenme eğrisi daha dik.

Aylık maliyet: Ücretsiz ila 39 dolar (SaaS), sunucu kurulumu kendi masrafınıza.

Jenkins

20 yıldan eski, açık kaynak CI/CD aracı. Esnekliğinde sınır neredeyse yoktur.

Avantaj: Yapabileceğiniz işler neredeyse sınırsız. Her kurumsal sistem ile entegre edilebilir.

Dezavantaj: Kurulum, bakım zor. Yetenekli sistem yöneticisi gerekir.

Maliyet: Ücretsiz ama sunucu maliyeti, sistem yönetimi zamanı hesaba katılmalıdır.

AWS CodePipeline

AWS ekosisteminde yaşıyorsanız, doğal seçim. Tüm AWS araçları ile entegredir.

Avantaj: AWS hizmetleri ile sorunsuz çalışır. Diğer AWS araçları ile kombinasyon kullanırken şaşırtıcı güçlü.

Dezavantaj: AWS dışı araçlar ile entegrasyon daha zor.

Aylık maliyet: Pipeline sayısına göre, ortalama 1 dolar per pipeline.

Pipeline Araçları Karşılaştırma Tablosu

Araç	Fiyat (Aylık)	Esneklik	Kurulum Zorluk	DevOps Gereksinimi	Enterprise Uyum
GitHub Actions	0-30 USD	Orta	Kolay	Düşük	İyi
GitLab CI/CD	0-39 USD	Çok Yüksek	Orta	Orta	Mükemmel
Jenkins	0 (self-hosted)	Sınırsız	Zor	Yüksek	Mükemmel
AWS CodePipeline	1 USD/pipeline	Orta	Orta	Orta	Mükemmel
CircleCI	15-1200 USD	Orta	Kolay	Düşük	İyi
Azure DevOps	0-2600 USD	Yüksek	Orta	Orta	Mükemmel

Seçim Kriterleri:

• Küçük takım (<10): GitHub Actions
• Aynı platform'da kod ve CI/CD: GitLab CI/CD
• Maksimum esneklik: Jenkins
• AWS'ye bağlı: AWS CodePipeline
• Microsoft ekosistemi: Azure DevOps

Pipeline Aşamaları Detaylı İncelemesi

Kod Taraması (Linting) ve Format

Kod yazıldığında, stil standartları otomatik kontrol edilir. Kurum içindeki ortak standartlar sağlanır.

Araç: Python için Black, JavaScript için Prettier, Go için gofmt, Java için Checkstyle.

Faydaları:

• Kod okunabilirliği artar
• PR review'da stil tartışması ortadan kalkar
• Kod rebase çatışmaları azalır

Ortalama süre: 10-30 saniye

Birim Testleri (Unit Tests)

Her fonksiyonun bağımsız davranışı test edilir. Geliştirici 50 satır kod yazdıysa, 100 satırlık test yazmalı. Bu karışık görünüyor ama, hataları önceden yakalar.

Test kapsamı (coverage), yüzde 80 altında olmamalı. Henüz yazılmayan kodu test etmeye çalışıyorsanız, kod tasarımı hatalı demektir.

Framework'ler: JUnit (Java), pytest (Python), Jest (JavaScript), RSpec (Ruby)

Başarılı müşteri örneği: Bir fintech şirketi birim testleri %85 coverage seviyesine çıkardığında, üretimde karşılaştığı kritik hataları 90% azalttı.

Ortalama süre: 2-10 dakika (parallel çalışıldığında 30-60 saniye)

Entegrasyon Testleri (Integration Tests)

Fonksiyonlar bir arada çalışırken test edilir. Veritabanı ile bağlantı kurulması, API çağrıları, dosya okuma, yazma testleri burada yapılır.

Örnek senaryolar:

• Database'e yazılan veri, doğru şekilde okunuyor mu?
• External API çağrısı başarısız olursa, fallback mekanizması çalışıyor mu?
• Cache invalidation doğru şekilde çalışıyor mu?

Ortalama süre: 5-15 dakika

Güvenlik Testleri (Security Scanning)

Kod, bilinen güvenlik açıkları için otomatik taranır. Bağımlılık kütüphaneleri, güncel güvenlik yamaları içeriyor mu kontrol edilir.

Araç: Snyk, OWASP Dependency-Check, Sonarqube, GitHub Advanced Security

Kontrol Listesi:

• SQL injection açıkları
• Cross-site scripting (XSS) zafiyetleri
• Hardcoded secrets (API key'ler, parolalar)
• Outdated dependencies ve known CVE'ler
• Encryption ve authentication eksiklikleri

Örnek: Ödeme sistemi şirketi, security scanning entegrasyonundan sonra, üretim ortamında 47 olası güvenlik açığını önceden tespit etti.

Ortalama süre: 3-8 dakika

Performans Testleri (Performance Testing)

Uygulamanız saniyede kaç istek işleyebilir? Veri tablosu 1 milyona çıktığında, sorgu hızı nasıl etkilenir? Bu testler, canlıya gitmeden önce ölçülür.

Load test aşamaları:

1. Baseline (normal yük): saniyede 100 request
2. Ramp-up (yükü kademeli artırma): 100'den 1000 istek/saniye
3. Peak (maksimum beklenen yük): 1000 istek/saniye
4. Stress test (kırılma noktası bulma): 2000+ istek/saniye

Araçlar: JMeter, Locust, Gatling

Ortalama süre: 5-20 dakika

Staging Ortamında Son Test

Canlı ortam ile tamamen aynı ayar, veri ve trafiğin aynı bir test ortamında, son kez doğrulama yapılır.

Kontrol Listesi:

• Tüm bağımlılıklar (veritabanı, external API'ler) bağlantılı
• Canlıdaki veri seti (anonimleştirilmiş) kullanılıyor
• Gerçek kullanıcı trafiği simülasyonu (synthetic monitoring)
• End-to-end user journey testleri

Ortalama süre: 10-30 dakika

Dağıtım Stratejileri

Blue-Green Dağıtım

İki aynı ortam vardır: mevcut (Blue) ve yeni (Green). Kullanıcılar Blue'dan hizmet alır. Green'e yeni sürüm dağıtılıp test edilir. Tamamlandığında, trafik Green'e yönlendirilir. Sorun çıkarsa, Blue'ya geri dönersiniz.

Avantaj: Sıfır kesinti, anında geri alma.

Dezavantaj: Iki tam ortam maliyeti. Veritabanı değişiklikleri yönetimi karmaşık olabilir.

Canary Dağıtım

Yeni sürüm, kullanıcıların yüzde 5'ine sunulur. Sorun çıkmazsa, yüzde 25, yüzde 50, yüzde 100 olarak yükseltilir.

Avantaj: Hataları küçük grup keşfeder. Gerçek kullanıcılardan geri bildirim alırsınız.

Dezavantaj: Dağıtım birkaç saat sürer.

Rolling Dağıtım

Sunucular birer birer güncellenir. Sunucu 1 yeni sürüm alırken, Sunucu 2, 3, 4 eski sürümden hizmet verir.

Avantaj: Maliyetli değil, yalnızca bir kaynakla yeterli.

Dezavantaj: Geçiş döneminde iki sürüm bir arada çalışmalı. Veritabanı şeması değişiklikleri risklidir.

Metrikleri İzlemek: DORA Metrikleri ve DevOps Başarısını Ölçmek

Google tarafından geliştirilen DORA (DevOps Research and Assessment) metrikleri, takım performansının en güvenilir göstergesidir:

1. Dağıtım Sıklığı (Deployment Frequency)

Ne sıklıkla canlıya kod gider?

Başarı Seviyeleri:

• Elite: Günde birden fazla (>1.000 deployment/yıl)
• High: Haftada 1-3 kez (100-999 deployment/yıl)
• Medium: Ayda 1-3 kez (13-99 deployment/yıl)
• Low: Ayda bir veya daha az (<13 deployment/yıl)

İlk aylarda hedef: Medium seviyesi 6 ay sonra hedef: High seviyesi 12 ay sonra hedef: Elite seviyesi

2. Lead Time for Changes (Değişim Süresi)

Kod yazılmasından canlıya gitmesine kadar geçen süre:

• Elite: 1 saatten az
• High: 1 saat - 1 gün
• Medium: 1-6 gün
• Low: 6 gün ve daha fazla

Iyileştirme yolu:

1. Ay 1-2: Test otomasyonunu artırma
2. Ay 3-4: Dağıtım sürecini hızlandırma
3. Ay 5-6: Feature flags ile daha küçük deploymentler

3. Mean Time to Recovery (MTTR)

Sorun çıktığında, ne kadar hızlı düzeltiliyor?

• Elite: 1 saatin altı
• High: 1 saat
• Medium: 1-24 saat
• Low: 24 saatin üzeri

İyileştirme stratejileri:

• Blue-green dağıtımla anlık geri alma
• Monitoring ve alerting sistemleri
• Runbook otomasyonu
• İncident response takımı eğitimi

4. Change Failure Rate

Canlıya gelen değişikliklerin yüzde kaçı sorun çıkartıyor?

• Elite: 0-15%
• High: 16-30%
• Medium: 31-45%
• Low: 46% ve üstü

Başarı Hikayesi: Bir e-ticaret müşterimiz CI/CD investisyonundan sonra:

• Deployment frequency: Ayda 1'den, günde 5'e (500% artış)
• Lead time: 2 haftadan, 2 saate (98% azalış)
• MTTR: 8 saatten, 15 dakikaya (96% azalış)
• Failure rate: 35%'ten, 8%'e (77% azalış)

Bu iyileştirmeler, yıllık 2 milyon lira maliyet tasarrufu sağlamıştır (daha hızlı özellik teslimi ve daha az insan hatası nedeniyle).

Metriklerin iyileşmesi, CI/CD investisyonunun doğrudan kanıtıdır. Hedef, bu dört metriği bir yıl içerisinde iyileştirmek, ikinci yılda ise Elite seviyesine ulaşmaktır.

CI/CD Kurulumda Yaygın Hatalar

Yetersiz Test Yazma: Pipeline hızlı olsa bile, testler eksik ise, hatalar canlıya gider. Test coverage yüzde 80'nin altında olmamalıdır.

Tüm Testlerin Seri Çalıştırması: Tests paralel çalıştırılmadığında, 100 test 20 dakika alabilir. Paralel çalışırsa 2 dakika. Pipeline hızı, test esnekliğine bağlıdır.

Canlıya Gitmeden Staging Ortamını Tutuşturma: Staging, canlı ile tamamen aynı olmalı. Farklı veritabanı, farklı config, farklı hata çıkarır.

İnsan Onayını Unutmak: Kritik değişiklikler (veri tabanı şeması, ödeme) otomatik dağıtılmamalı. İki kişinin onay vermesi güvenlik getiri.

CI/CD Kurulumda Yaygın Hatalar ve Çözümleri

Hata 1: Yetersiz Test Yazma

Sorun: Pipeline hızlı çalışsa bile, testler eksik ise, hatalar canlıya gider ve saatler süren incident'ler başlatır.

Çözüm:

• Test coverage yüzde 80'nin altında olmamalı
• Birim testlerden başlayıp, integration testlerine genişleyin
• Production'dan alınan gerçek veri setleriyle test yapın

Hedef:

• Ay 1: Test coverage 30%'e çıkarmak
• Ay 3: Test coverage 60%'e çıkarmak
• Ay 6: Test coverage 80%+ seviyesine ulaşmak

Hata 2: Tüm Testlerin Seri Çalıştırması

Sorun: Tests paralel çalıştırılmadığında, 100 test 20 dakika alabilir. Bu pipeline'ı yavaş yapar ve geliştirici üretkenliğini azaltır.

Çözüm:

• Tüm testleri paralel çalıştıracak şekilde yapılandırma
• Test bağımlılıklarını ortadan kaldırma (her test bağımsız olmalı)
• Test veritabanı instance'ı (her test için ayrı)

Sonuç: 20 dakika test 2 dakikaya düşer (90% hızlanma)

Hata 3: Canlıya Gitmeden Staging Ortamını Tutuşturma

Sorun: Staging, canlı ile farklı olursa, staging'de çalışan kod canlıda çöker. Bu kullanıcı memnuniyetini düşürür ve uykuları kaçırır.

Çözüm:

• Staging'i canlı ile tamamen aynı yapılandırmak (Infrastructure as Code kullanarak)
• Canlı veritabanının anonimleştirilmiş kopyasını staging'de kullanmak
• Gerçek trafiği simüle eden load testler çalıştırmak

Kontrol Listesi:

• DNS ve domain ayarları aynı mı?
• SSL sertifikaları güncel mi?
• Database replication ayarlanmış mı?
• Tüm external API integrasyonları çalışıyor mu?

Hata 4: İnsan Onayını Unutmak

Sorun: Kritik değişiklikler (veri tabanı şeması değişiklikleri, ödeme sistemi güncellemeleri) otomatik dağıtılırsa, oluşan sorunlar kontrol dışı olabilir.

Çözüm:

• Kritik değişiklikler (tagged deployment'lar) için manuel approval gerekli
• En az iki kişinin onay vermesi (four-eyes principle)
• Approval'dan sonra 24 saat log tutma (audit trail)

Hata 5: Monitoring ve Alerting'i Sonradan Kurmak

Sorun: Deployment yapılıp, sorun çıkarsa, ancak monitoring olmazsa, sorunun ne olduğu saatlerce bilinmeyebilir.

Çözüm:

• Day 1'den monitoring kurma
• Kritik metrikler (CPU, memory, error rate, response time) otomatik izleme
• Eşik değerlere ulaşılınca otomatik alert gönderme (Slack, PagerDuty, etc.)
• Ön tanılı dashboard'lar oluşturma

Smart Maple'ın CI/CD Yaklaşımı

Smart Maple, 200+ kurumsal müşteri için CI/CD pipeline kurmuş, yüzlerce hata ve en iyi uygulamayı öğrenmiş bir ekiptir. Geliştirme hızı artırırken, kaliteyi ve güvenliği korumak, bizim uzmanlaştığımız alandır.

Yaklaşımımız:

1. Mevcut durum analizi (AS-IS)
2. Hedef durum tanımlama (TO-BE)
3. Araç seçimi ve mimarı tasarlanması
4. Pilot project ile PoC
5. Takım eğitimi ve full rollout
6. Sürekli iyileştirme ve optimization

Herhangi bir araç ile başlamış olun (GitHub, GitLab, Jenkins, AWS), mimarinizi gözden geçireceğiz, özellikle ödeme sistemleri ve hassas işlemler etrafında, güvenliğin iyileştirilmesi önerebiliriz.

Bulut bilişim ve DevOps stratejileri hakkında derinleşmek için bulut bilişim rehberimize bakın. Ayrıca konteyner yönetimi rehberimiz de CI/CD ile birlikte kullanılabilen teknikler sunar. Bulut göç stratejisi rehberimiz de CI/CD'nin göç sırasında değişimin hızını nasıl artırdığını açıklar.

Yazılım teslim hızını ve kalitesini dönüştürmek için smart-maple.com ile iletişime geçin. İş hedeflerinize uyan, kendi altyapınıza uygun bir CI/CD mimarisi tasarlayalım. DORA metrikleri aracılığıyla, takım performansını ölçebilir ve iyileştirebiliriz.