CI/CD Pipeline’ı Sıfırdan Kurdum — Bastığım Mayınlar

“CI/CD kuralım” dedim, 3 gece uyumadım. GitHub Actions’a bir YAML dosyası yazdım, kırmızı “failed” ekranından gözlerim yandı. Pipeline’ım beni 47 kez yanılttı — her seferinde farklı bir sebepten. Bu yazıda CI/CD pipeline’ını sıfırdan kurarken bastığım mayınları, 3 gecelik çilemi ve sonunda her şeyin yeşil olduğu o anı anlatıyorum.

GitHub’un 2025 yılı verilerine göre, geliştiriciler toplam 11,5 milyar dakika CPU süresi harcamış GitHub Actions üzerinde — bir önceki yıla göre %35 artış. Ben de bu 11,5 milyar dakikadan birkaç yüzünü kapattım ama her dakikası bir çileydi. (GitHub Octoverse 2025)

CI/CD Nedir ve Neden Kendi Ellerimle Kurdum?

CI/CD, sürekli entegrasyon ve sürekli dağıtım demek. Kod yazıyorsunuz, push’luyorsunuz ve sistem otomatik olarak derliyor, test ediyor, sunucuya gönderiyor. Manuel deploy’un yerini alıyor — yani gece 2’de “bir değişiklik yapayım, sunucuya atayım” deyip her şeyin çökme riskini ortadan kaldırıyor.

DORA raporuna göre, üstün performans gösteren ekipler düşük performanslı ekiplere göre günde 973 kat daha sık deploy yapıyor. Ben ise deploy başına ortalama 45 dakika harcıyordum — SSH ile sunucuya gir, git pull yap, bağımlılıkları güncelle, servisleri yeniden başlat. Her seferinde bir şey unutuyordum. (Google Cloud DORA State of DevOps 2021)

İlk Mayın: YAML ve Girintiler

GitHub Actions ile başladım. “Ne kadar zor olabilir?” dedim. Bir .github/workflows/deploy.yml dosyası yazacaktım sadece. Ama YAML’in girinti kuralları beni çıldırttı. İki space yerine tab kullandım, pipeline kırmızı oldu. Bir yere fazladan space bıraktım, syntax error. 2 saatimi tek bir girinti hatasına harcadım.

Stack Overflow 2024 anketine göre, geliştiricilerin %59’u Docker’ı build ve test aracı olarak kullanıyor. Ben de Docker kullandım ama Dockerfile’ı yanlış yazınca pipeline 12 dakika çalışıp sonra patladı — her deneme 12 dakika beklemek demek. (Stack Overflow Developer Survey 2024)

YAML dosyamın ilk hali şuna benziyordu:

name: Deploy
on: push
jobs:
  build:
  runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - run: npm install
    - run: npm test

Bu dosyada 3 hata var. Gördünüz mü? Ben görmedim — 4 kez deneyip her seferinde farklı bir hata mesajı aldım. runs-on girintisi yanlış. steps altında olmalı. npm test çalıştı ama test dosyası yoktu. Mayın mayın mayın.

İkinci Mayın: Environment Değişkenleri

Local’de çalışan şey GitHub Actions’da çalışmıyor. Neden? Çünkü local’deki .env dosyanız Actions runner’da yok. Veritabanı bağlantısı, API anahtarları, secret’lar — hepsini GitHub Secrets’a eklemeniz gerekiyor. Ben bunu bilmiyordum.

Pipeline’ım veritabanına bağlanmaya çalıştı, connection string bulamadı, 8 dakika timeout bekledi ve patladı. Hata mesajı: ECONNREFUSED. “Sunucu mu kapandı?” dedim, hayır — sadece environment variable tanımlı değildi.

GitHub Secrets’a ekledim ama bu sefer de YAML’de yanlış syntax ile çağırdım. $SECRET yazdım, olması gereken ${{ secrets.SECRET }} idi. Bu da 2 saat.

Üçüncü Mayın: Flaky Testler ve Sahte Hatalar

Pipeline’ımdaki en sinir bozucu şey: bazen çalışıp bazen çalışmayan testler. “Flaky test” diyorlar buna. Push’luyorum, testler geçiyor. Bir saat sonra tekrar push’luyorum, aynı testler patlıyor. Kod değişmedi ama sonuç farklı.

DORA verilerine göre, üstün performanslı ekiplerin change failure oranı %0-15 arası. Düşük performanslı ekiplerde ise %16-30. Benim ilk haftamda failure oranı %70’ti — 10 push’un 7’sinde pipeline patlıyordu. Ve bunun yarısı gerçek hata değildi, flaky testlerdi. (Google Cloud DORA State of DevOps 2021)

Dördüncü Mayın: Docker Image Boyutu ve Cache

Docker image’ım 2.3 GB’dı. Her push’ta 2.3 GB build edilip push ediliyordu. GitHub Actions runner’da bu 15-20 dakika sürüyordu. Bir gün 8 kez push yaptım — 3 saatimi sadece Docker build bekleyerek geçirdim.

GitHub’un 2025 verilerine göre, 1,9 milyon repository Dockerfile kullanıyor ve bu bir önceki yıla göre %120 artış gösteriyor. Docker popüler ama Dockerfile yazmak ayrı bir yetenek. Ben multi-stage build’i sonradan öğrendim — image boyutunu 2.3 GB’dan 340 MB’a düşürdüm. (GitHub Octoverse 2025)

Cache mekanizmasını keşfetmem de zaman aldı. GitHub Actions’da actions/cache ile node_modules cache’leyebiliyorsunuz. Bu ekleme, build süresini 12 dakikadan 3 dakikaya düşürdü. Keşke baştan yapsaydım.

Beşinci Mayın: Deployment Stratejisi

“Build ettik, şimdi sunucuya atıyoruz” dedim. Ama nasıl? SSH ile mi? FTP ile mi? Docker pull ile mi? Her stratejinin artıları ve eksileri var. Ben SSH ile başladım — basit ama tehlikeli.

SSH key’ini GitHub Secrets’a ekledim, pipeline sunucuya bağlanıp git pull ve docker-compose up yapıyordu. Bir gün pipeline deploy sırasında patladı ve sunucuda container’lar yarım kaldı. Site 3 saat kapalı kaldı. Artık rolling deployment yapıyorum — eski container’ı kapatmadan önce yenisini başlatıyorum.

DORA üstün performanslı ekiplerin değişim için lead time’ı 1 saatin altında. Düşük performanslı ekiplerde ise 6 ayın üstünde. Benim ilk kurulumumda lead time 2 saatti — şimdi 8 dakika. (Google Cloud DORA State of DevOps 2021)

Pipeline’ımın Son Hali — Çalışıyor Sonunda

3 gece, 47 failed build ve çok sayıda kahve sonrasında pipeline’ım çalışır hale geldi. İşte yapı:

name: Deploy
on:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to server
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd /app
            git pull origin main
            docker compose up -d --build

Bu YAML dosyası test aşamasını ve deploy aşamasını ayırıyor. Test patlarsa deploy çalışmıyor. Docker compose ile rolling update yapılıyor. Ve cache sayesinde build süreleri makul seviyede.

Öğrendiğim 7 Ders

1. Önce local’de test et — act aracıyla GitHub Actions’ı local’de çalıştırabilirsiniz. Keşke baştan kullansaydım.
2. Secret’ları erken tanımla — Her environment variable için GitHub Secrets’a gidin. Sonradan eklemek her seferinde 10 dakika beklemek demek.
3. Cache kullan — actions/cache veya setup-node cache’i. Build süreçlerini 3-4 kat hızlandırıyor.
4. Flaky testleri temizle — Bazen çalışan bazen çalışmayan testi disable edin. Pipeline’ınızın güvenilirliği her şeyden önemli.
5. Multi-stage Docker build kullan — Image boyutunu 5-10 kat küçültüyor. Build süresi düşüyor, deploy hızlanıyor.
6. Rolling deployment yap — Eski container’ı kapatmadan yenisini başlatın. Yoksa deploy sırasında site gider.
7. Monitoring ekle — Pipeline patladığında Slack veya Discord’a bildirim gitsin. Ben 3 saat fark etmeden site kapalı kaldı.

Maliyet: Ücretsiz Plan Yeterli mi?

GitHub Actions ücretsiz planı ayda 2.000 dakika veriyor. Benim pipeline’ım her çalışmada ortalama 8 dakika tüketiyor. Günde 5-6 push yapıyorum. Bu ayda yaklaşık 1.200-1.500 dakika yapıyor. Ücretsiz plan yetiyor — şimdilik.

Ama Dependabot’la birlikte kullanıyorsanız dakika tüketimi artıyor. GitHub’un 2025 verilerine göre 2,66 milyondan fazla repository’de Dependabot aktif ve bu sayı yıllık %24 artıyor. Kritik güvenlik açıklarının ortalama düzeltilme süresi %30 iyileşmiş. (GitHub Octoverse 2025)

Sıkça Sorulan Sorular

CI/CD kurmak için ne kadar zaman gerekiyor?

Basit bir pipeline için 1-2 gün. Benim gibi ilk defa kuruyorsanız ve her hatayı kendiniz çözüyorsanız 3-5 gün. Daha önce deneyimi olan biri 4-5 saatte kurabilir. Önemli olan ilk mayını patlatıp öğrendikten sonra hızlanması.

GitHub Actions mı GitLab CI mı Jenkins mi?

GitHub kullanıyorsanız Actions en kolay seçenek. GitLab CI kendi platformunda güçlü. Jenkins ise esnek ama kurulumu ve bakımı zor. Ben GitHub Actions ile başladım ve memnunum — YAML yazmak dışında bir şey öğrenmeye gerek yok.

CI/CD olmadan yaşanabilir mi?

Teknik olarak evet. Ama her deploy’da 45 dakika harcamak, bir şey unutmak ve siteyi düşürmek can sıkıcı. DORA verilerine göre üstün ekipler saatte birden fazla deploy yapıyor — manuel bununla başa çıkamaz.

Ücretsiz CI/CD araçları hangileri?

GitHub Actions (2.000 dk/ay ücretsiz), GitLab CI (400 dk/ay ücretsiz), CircleCI (6.000 dk/ay ücretsiz). Küçük projeler için hepsi yeterli. Büyük projeler için ücretli plan gerekiyor.

Pipeline patladığında ne yapmalı?

Önce log’u okuyun. %80 oranında sorun ya environment variable eksikliği ya da syntax hatası. Sonra local’de reproduce edin. Reproduce edemiyorsanız flaky test şüphelenin. Ve asla “çalıştı bir ara bakarım” demeyin — o “bir ara” hiç gelmiyor.

Sonuç

CI/CD pipeline’ını sıfırdan kurdum, 47 mayın patlattım ve sonunda her şey yeşil oldu. Artık push yapıyorum ve bir kaç dakika (proje özelinde 8dk) sonra sunucumda değişiklik canlı. Gece 2’de deploy yapmaktan korkmuyorum. Site kapalı kalma sürem dakikalardan 0’a indi.

CI/CD öğrenmek zor ama bir kere kurduğunuzda geri dönülemez. Manuel deploy’a dönmek, kasetçalar kullanmaya dönmek gibi. Zor olan kısmı başlangıç — sonrasında her şey otomatik. Ben 3 gece harcadım ama şimdi her deploy 45 dakikadan 8 dakikaya düştü. Değer mi? Kesinlikle değer.