CI/CD Pipeline Kurulumu

GitHub Actions Workflow Yapısı

GitHub Actions ücretsiz tier, public repository'lerde sınırsız dakika sunarken private repository'lerde aylık 2.000 dakika sağlar. Temel bir workflow beş aşamadan oluşur: push tetikleyicisi → lint (kod kalitesi) → test → build → deploy. Her aşama ayrı bir job olarak tanımlanmalıdır; böylece lint hatası testi çalıştırmadan durdurur ve başarısızlığın kaynağı hızla bulunur.

Workflow dosyası .github/workflows/ci.yml yolunda YAML formatında tanımlanır. on: push: branches: [main, develop] ile ana dal ve geliştirme dalına push tetikleyicisi kurulur; on: pull_request ise her PR açıldığında kontrol çalıştırır. Job'lar arasında needs: [lint, test] ile bağımlılık zinciri kurmak, hem paralel çalıştırmayı hem de sıralı zorunluluğu bir arada sağlar. Actions marketplace'de binlerce hazır action bulunuyor; ancak her eklenen action bir tedarik zinciri güvenlik riski olduğundan yalnızca güvenilir kaynaklardan, sabitlenmiş bir commit hash'iyle kullan.

Test Otomasyonu Entegrasyonu

Unit testleri Jest veya Vitest ile, uçtan uca (e2e) testleri Playwright veya Cypress ile yaz. GitHub Actions'ta npx playwright test komutu headless Chromium ile çalışır; Playwright'ın otomatik browser kurulum adımı npx playwright install --with-deps ile workflow'a eklenir. E2e testler en uzun süren aşamadır; kritik kullanıcı akışlarını (kayıt, ödeme, temel CRUD) öncelikle kapsayan bir suite oluştur ve tüm uygulama için tam kapsama hırsından kaçın.

Test güvenilirliğini (flakiness) izle: aynı kod değişikliği olmadan bazen geçen, bazen geçemeyen testler CI sürecine güveni zedeler. Playwright'ın retry mekanizması (retries: 2) bazı geçici hataları emmesine rağmen gerçek flaky test'leri maskeler; bunları izole et ve sabit düzeltmeler yap. test.describe.parallel ile bağımsız test gruplarını eş zamanlı çalıştırmak toplam test süresini yarıya indirebilir.

Staging Ortamı

Branch stratejisi CI/CD'nin omurgasıdır: main branch production'a, develop branch staging'e, her feature branch ise kendi preview ortamına deploy edilir. Vercel bu modeli otomatik destekler; her PR için preview URL oluşturur ve PR kapandığında ortamı temizler. Bu yapı QA sürecini dramatik biçimde basitleştirir: her değişiklik production'a gitmeden önce gerçek bir URL üzerinde test edilebilir.

Staging ortamının production verisine bağlanması hem güvenlik riski hem de test güvenilirliği sorunu yaratır; production veritabanının anonimleştirilmiş kopyasını staging'e düzenli aralıklarla seeding yapmak daha sağlıklı bir yaklaşımdır. Staging ortam değişkenleri (API anahtarları, veritabanı URL'leri) production ile ayrı tutulmalı; test ödeme geçidine, sandbox API'larına ve ayrı bir veritabanına bağlanmalıdır.

Zero-Downtime Deployment

Vercel ve Railway deploy sırasında kesinti yaşatmaz; yeni build hazır olduğunda trafik sorunsuz yeni versiyona yönlenir ve önceki build silinmeden önce eski istekler tamamlanır. Kendi sunucunda deploy yapıyorsan blue-green deployment bu garantiyi elle kurmanın standart yoludur: iki özdeş ortam çalışır, yeni sürüm "blue"ya deploy edilir, sağlık kontrolü geçince trafik "green"den "blue"ya anahtarlanır.

Her deploy edilebilir uygulama için sağlık kontrolü endpoint'i zorunludur: /api/health endpoint'i veritabanı bağlantısını, kritik bir bağımlılık servisini ve bellek kullanımını kontrol edip {"status": "ok"} döndürmelidir. Load balancer veya deployment platformu bu endpoint'i kullanarak yeni versiyonun canlıya alınmaya hazır olup olmadığını anlar. Health check'i olmayan bir uygulama hatalı bir versiyonla saatlerce canlıda kalabilir.

Sık Sorulan Sorular

GitHub Actions dakika sınırına ulaşırsam ne yapabilirim? Önce workflow optimizasyonu: cache kullan (actions/cache ile node_modules önbellekle), paralel job'ları birleştir ve gereksiz adımları çıkar. Yetmiyorsa GitHub'ın ücretli planları ek dakika sunar veya Gitea Actions / GitLab CI gibi self-hosted alternatifler değerlendirilebilir.

Hangi testler CI'da mutlaka çalışmalı? Unit testler ve kritik e2e senaryoları her PR'da çalışmalı. Tüm e2e suite uzun sürüyorsa sadece smoke test'leri PR'da çalıştır; tam suite gece zamanlamasıyla main branch'e push edildiğinde tetiklensin.

Secrets'ı GitHub Actions'ta nasıl kullanırım? GitHub repository Settings > Secrets and Variables > Actions bölümünden ekle. Workflow'da ${{ secrets.MY_SECRET }} ile erişilir; log'larda otomatik maskelenir. Bu değerleri workflow dosyasında plain text olarak asla yazma.

Preview ortam ile staging ortamı aynı şey mi? Hayır; preview ortam her PR için otomatik oluşturulan geçici bir ortamdır. Staging ise develop branch'inin her zaman deploy edildiği kalıcı bir ortamdır. QA ekibi staging'de test eder; PR yazarları preview'da kontrol eder.

Zero-downtime deployment için veritabanı migration'ları nasıl yönetilir? Migration'ların her zaman backward-compatible olmasına dikkat et: yeni sütun ekleme eski kodu bozmaz; sütun silme eski kodu bozar. Büyük schema değişikliklerini birden fazla deploy'a yay: önce yeni sütunu ekle (deploy), ardından eski kodu kaldır (ikinci deploy), en son eski sütunu sil (üçüncü deploy).