Özel yazılım projelerinde canlıya çıkış süreci, çoğu zaman kod yazmaktan daha risklidir. Geliştirme ortamında sorunsuz çalışan bir özellik, testte farklı davranabilir; canlıda ise bağımlılık, konfigürasyon ya da insan hatası nedeniyle kesinti yaratabilir. Tam da bu noktada ci cd pipeline devreye girer. Amaç yalnızca dağıtımı otomatikleştirmek değildir. Asıl hedef, koddaki her değişikliği aynı adımlardan geçirerek daha hızlı, daha az hatayla ve denetlenebilir biçimde yayına almaktır.
İyi tasarlanmış bir pipeline, bir commit’in ardından dakikalar içinde derleme, test, güvenlik taraması ve dağıtım adımlarını çalıştırır. Ekip 4 geliştiriciden oluşsa da 40 kişiye çıksa da süreç standardı korunur. Kurumlar açısından değer üreten taraf da budur: kişiye bağlı operasyon azalır, sürüm geçmişi kayıt altına alınır, rollback süresi kısalır.
Bu rehberde bir ci cd pipeline yapısını pratik açıdan ele alacağız. Hangi aşamalar gerekir, hangi kontroller zorunludur, özel yazılım projelerinde hangi mimari seçimler işleri kolaylaştırır; adım adım bakalım.
CI/CD pipeline nedir ve neden gereklidir?
CI, yani Continuous Integration, geliştiricilerin yaptığı değişikliklerin sık aralıklarla ortak depoya alınmasını ve otomatik olarak doğrulanmasını ifade eder. CD ise iki farklı anlamda kullanılır: Continuous Delivery ve Continuous Deployment. İlkinde sistem dağıtıma her an hazır tutulur, yayına alma kararı genellikle onayla verilir. İkincisinde ise testleri geçen sürüm otomatik olarak canlıya çıkar.
Basit bir örnek düşünelim. E-ticaret için geliştirilen özel bir B2B sipariş platformunda ekip günde 15 commit atıyor olsun. Pipeline yoksa derleme yerelde çalışır, testler zaman zaman atlanır, staging’e manuel kopyalama yapılır. Bu model birkaç hafta idare edebilir; ancak sürüm sayısı arttığında aynı iş akışı kırılgan hale gelir. Pipeline ile ise her commit sonrasında aynı 6-8 kontrol devreye alınabilir: bağımlılık kurulumu, build, unit test, lint, güvenlik taraması, artifact üretimi, staging deploy, smoke test.
Buradaki temel kazanım yalnızca hız değil, tutarlılıktır. Aynı komutların her ortamda aynı sırayla çalışması, “bende çalışıyordu” sorununu belirgin biçimde azaltır.
Kuruluma başlamadan önce netleştirilmesi gereken 5 karar
Pipeline araçlarını seçmeden önce proje gerçekleri netleşmelidir. Aksi halde GitHub Actions, GitLab CI veya Jenkins seçmek tek başına sorunu çözmez.
1. Dağıtım hedefiniz nedir?
Uygulama bir sanal sunucuya mı çıkacak, Docker container olarak mı çalışacak, Kubernetes üzerinde mi yönetilecek? Örneğin tek bir VPS üzerinde çalışan .NET ya da Node.js uygulaması için pipeline daha kısa kurulabilir. Kubernetes tarafında ise image build, registry push, manifest güncelleme ve rollout kontrolü gibi ek aşamalar gerekir.
2. Ortamlar kaç adet?
En az 3 ortam önerilir: dev, staging, production. Küçük projelerde 2 ortamla başlanabilir; yine de test ve canlı ortamının ayrılması kritik önem taşır. Özellikle API entegrasyonlu işlerde staging ortamında gerçek servislere benzeyen taklit uçların bulunması ciddi fark yaratır.
3. Test seviyesi ne olacak?
Minimum seviyede unit test ve smoke test gerekir. Ödeme, sipariş, stok, kullanıcı yetkisi gibi kritik akışlar varsa entegrasyon testleri de pipeline’a eklenmelidir. 10 dakikayı aşan test paketleri varsa bunlar paralel çalıştırılmalı ya da risk bazlı ayrılmalıdır.
4. Onay mekanizması manuel mi?
Kurumsal projelerde production deploy öncesinde tek tuşlu onay yaygındır. Finans, sağlık veya lojistik alanında tamamen otomatik canlı geçiş yerine onay kapısı kullanmak daha güvenli olabilir.
5. Geri dönüş stratejiniz hazır mı?
Deploy kadar rollback de otomatik düşünülmelidir. Son çalışan container image etiketi, önceki artifact sürümü veya veritabanı migration geri alma planı baştan tanımlanmazsa pipeline eksik kalır.
CI/CD pipeline mimarisi: minimum uygulanabilir akış
Pratikte çoğu özel yazılım projesi için başlangıç seviyesinde yeterli bir akış aşağıdaki gibidir:
- Kod push veya pull request tetiklenir
- Bağımlılıklar temiz ortamda kurulur
- Build alınır
- Statik analiz ve lint çalışır
- Unit testler çalışır
- Güvenlik ve dependency taraması yapılır
- Artifact veya Docker image üretilir
- Staging ortama dağıtım yapılır
- Smoke test ve temel sağlık kontrolleri koşar
- Onay sonrası production deploy yapılır
Bu zincirin toplam süresi proje tipine göre değişir. Hafif bir API servisinde 4-8 dakika makul olabilir. Daha büyük monolitlerde süre 15 dakikanın üzerine çıkabilir. Burada önemli olan tek hedefin “en kısa süre” olmamasıdır; güvenilirlikten ödün vermeden akışı ölçülebilir hale getirmektir.
Örnek iş akışı senaryosu
Bir depo yönetim uygulamasında barkod okutma modülünde hata düzeltmesi yapıldığını düşünelim. Geliştirici feature branch’e commit atar. Pull request açılınca pipeline otomatik olarak çalışır, testler geçer, image oluşturulur, staging’e alınır. Operasyon ekibi staging’de 2-3 kritik senaryoyu doğrular. Ardından production onayı verilir. Deploy tamamlanınca /health endpoint’i 200 döner, eski sürüm etiketi de rollback için saklanır. Süreç kayıt altındadır; kim, ne zaman, hangi commit’i yayına aldı görülebilir.
Adım adım kurulum: Git, build, test, deploy
1. Kaynak kod stratejisini belirleyin
Branch yapısı sade olmalıdır. Birçok ekip için main + kısa ömürlü feature branch modeli yeterlidir. Her pull request pipeline’ı tetiklemeli, doğrudan main’e push sınırlandırılmalıdır. En az 1 kod inceleme kuralı eklemek, hataları erken yakalamaya yardımcı olur.
2. Build ortamını standartlaştırın
Yerel makinelerde çalışan ama CI sunucusunda patlayan işler genellikle sürüm farkından kaynaklanır. Node.js 20, .NET 8, Java 21 gibi çalışma zamanı sürümleri pipeline içinde açıkça tanımlanmalıdır. Container tabanlı build yaklaşımı burada güçlüdür; çünkü her koşum temiz bir ortamda başlar.
3. Testleri katmanlayın
Her şeyi tek aşamada koşturmak yerine testleri amaçlarına göre ayırın. Unit testler 1-3 dakika içinde bitebilir. Entegrasyon testleri daha uzun sürüyorsa ayrı job olarak paralel çalışabilir. UI testleri her commit’te değil, belirli branch’lerde veya gece koşularında tetiklenebilir.
4. Artifact üretin
Deploy sırasında yeniden build almak yerine, testten geçmiş artifact’i dağıtmak daha güvenli bir yaklaşımdır. Bu artifact bir Docker image, .jar dosyası, .zip paket ya da derlenmiş frontend çıktısı olabilir. Etiketleme için commit SHA kullanmak izlenebilirlik sağlar.
5. Staging ve production dağıtımlarını ayırın
İki ortama da aynı script ile, yalnızca değişkenler farklı olacak şekilde çıkmak iyi bir pratiktir. Ortamlar arasındaki fark ne kadar azalırsa sürprizler de o kadar azalır. Örneğin veritabanı bağlantısı, API anahtarları ve domain bilgileri secret yönetimi üzerinden verilmelidir; kod içine yazılmamalıdır.
6. Basit bir YAML örneğiyle düşünelim
name: ci
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm run lint
- run: npm test
- run: npm run build
Bu örnek üretim için yeterli değildir; ancak iskeleti gösterir. Gerçek projede cache, secret yönetimi, artifact saklama, deploy job’ları ve ortam onayları eklenir.
Güvenlik, secret yönetimi ve izlenebilirlik
Bir ci cd pipeline yalnızca hız aracı olarak kurgulanırsa risk de üretir. Özellikle özel yazılım projelerinde müşteri verisi, üçüncü parti entegrasyon anahtarları ve altyapı erişimleri dikkatle yönetilmelidir.
İlk kural nettir: Secret bilgileri repo içinde tutulmaz. CI platformunun secret store özelliği, bulut sağlayıcısının key vault servisi veya HashiCorp Vault benzeri bir çözüm kullanılmalıdır. Erişimler rol bazlı verilmeli, üretim anahtarları yalnızca ilgili deploy job’larında görünmelidir.
İkinci kritik başlık log ve audit kaydıdır. Kim deploy başlattı, hangi commit çıktı, hangi testler geçti, hata hangi adımda oluştu; bunların tamamı geriye dönük izlenebilmelidir. Bir hata anında 30 dakikalık araştırmayı 5 dakikaya indiren şey, çoğu zaman bu kayıtlardır.
Üçüncü nokta bağımlılık güvenliğidir. Açık kaynak paket taramaları, container image zafiyet kontrolleri ve temel SAST adımları pipeline’a eklenebilir. Buradaki amaç “sıfır risk” iddiası değil, bilinen riskleri mümkün olduğunca erken yakalamaktır.
Sık yapılan hatalar ve nasıl önlenir?
Özel yazılım ekiplerinde benzer sorunlar tekrar eder. Bunları en baştan görmek, kurulum süresini ciddi biçimde kısaltır.
- Pipeline’ı çok erken karmaşıklaştırmak: İlk günden 25 aşamalı bir akış kurmak yerine, çalışan minimum modelle başlamak daha sağlıklıdır.
- Testi olmayan projede deploy otomasyonu beklemek: Test temeli zayıfsa otomasyon yalnızca hatayı daha hızlı taşır.
- Ortam farklarını görmezden gelmek: Staging ve production arasında işletim sistemi, sürüm veya ağ farkı varsa pipeline’a duyulan güven düşer.
- Migration planı yazmamak: Veritabanı değişiklikleri sürümleme olmadan yönetilirse deploy geri dönüşü zorlaşır.
- Bildirim ve izleme kurmamak: Başarısız job sonrasında ekip haberdar olmuyorsa otomasyonun etkisi sınırlı kalır.
İlk 30 gün için gerçekçi hedef şudur: her merge sonrasında otomatik test, staging deploy ve kayıtlı sürüm geçmişi. Production otomasyonu ise bir sonraki aşamada olgunlaştırılabilir.
Hangi araçlar tercih edilebilir?
Tek bir doğru araç yoktur. Karar, ekibin teknik yapısına ve mevcut ekosistemine bağlıdır.
GitHub Actions, GitHub üzerinde yaşayan projelerde hızlı başlangıç sağlar. GitLab CI, repo ve CI süreçlerini tek platformda toplamak isteyen ekipler için güçlü bir seçenektir. Jenkins ise daha esnek, fakat bakım yükü yüksek bir alternatiftir. Bulut tarafında Azure DevOps, Bitbucket Pipelines veya AWS CodePipeline gibi servisler de kullanılabilir.
Seçim yaparken 4 ölçüte bakmak yeterlidir: bakım maliyeti, secret yönetimi, ortam onayı desteği, ölçeklenebilir runner yapısı. 6 ay sonra yönetilemeyecek kadar karmaşık bir araç yerine, ekibin sürdürebileceği sade bir çözüm daha değerlidir.
Kapanış
Sağlam bir ci cd pipeline kurmak yalnızca DevOps ekibinin işi değildir; yazılım geliştirme, test ve operasyon disiplinlerinin ortak çalışma biçimidir. Doğru kurgulandığında canlıya çıkış süresi kısalır, hata riski düşer, sürüm geçmişi daha şeffaf hale gelir. En kritik nokta ise şudur: pipeline bir dosya değil, işletilen bir süreçtir. Küçük başlayın, ölçün, darboğazları görün ve adım adım olgunlaştırın. Özel yazılım projelerinde kalıcı verim artışı da tam olarak böyle oluşur.
