Geldiğim takımda CI pipeline 20 dakika sürüyordu. Her pull request için iki kez çalışıyordu (PR açılışta, merge öncesi). Geliştiriciler “ben build bekleyeyim” diye Slack’e kaçıyordu, günün önemli bir kısmı boşta geçiyordu. İki haftada 4 dakikaya indirdik, pipeline’ı yeniden yazmadan, varolan adımları optimize ederek. Adım adım paylaşayım.
Başlangıç durumu
- Lint: 2 dakika
- Unit test: 5 dakika
- Integration test: 7 dakika
- Build: 4 dakika
- Deploy (staging): 2 dakika
- Total: ~20 dakika
Pipeline GitLab CI idi, Kubernetes runner üzerinde, cache mekanizması yarı kurulu. Her aşama yeni container başlatıyordu.
Adım 1: Docker layer caching (kazanım: 4 dakika)
Build aşaması her seferinde npm install + composer install çalıştırıyordu. Bu tek başına 3 dakika. Dockerfile’da katmanlama yanlıştı, paket lock file’ından önce kod kopyalanıyordu, yani her küçük kod değişikliği cache’i bozuyordu.
Dockerfile’ı yeniden sıraladım:
COPY package-lock.json composer.lock ./
RUN npm ci && composer install --no-dev
COPY . .
RUN npm run buildPaket dosyaları değişmedikçe dependency install’u cache’ten geliyor. Ayrıca GitLab registry’yi Docker cache backend olarak ayarladık. Build süresi 4 dakikadan 30 saniyeye düştü.
Adım 2: Test paralelleştirme (kazanım: 6 dakika)
Unit test (5 dk) ve integration test (7 dk) sıralı çalışıyordu. Paralel çalışacak şekilde job split yaptık. Ayrıca integration testleri konularına göre 3 parçaya böldük, paralel koştuk. Pipeline Y-yapıda akmaya başladı.
Unit 5 dakika, Integration 3 dakikaya (en uzun parça) indi. Birlikte 12’den 5’e.
Adım 3: Lint incremental (kazanım: 1.5 dakika)
Lint tüm proje üzerinde her seferinde çalışıyordu, 2 dakika. ESLint + PHPCS + Prettier. Oysa PR’da değişen dosya sayısı ortalama 8. git diff --name-only origin/main...HEAD ile değişen dosyaları alıp sadece onlara lint uyguladık. 30 saniyeye indi.
Bir güvence: commit öncesi pre-commit hook ile zaten çalışıyordu, yani CI’da sadece kontrol amaçlıydı. Tam proje lint’i nightly bir job’a taşıdık.
Adım 4: Veritabanı seed cache (kazanım: 2 dakika)
Integration test başlangıcında migration + seed çalışıyordu, 2 dakika. Bu hiç değişmiyordu. MySQL’i snapshot alıp image olarak sakladık. Job başlarken snapshot’tan restore ediyor, 10 saniyede hazır.
Adım 5: Daha güçlü runner (kazanım: 1 dakika)
Runner 2 vCPU / 4 GB idi. Build ve test CPU bound’du. 4 vCPU / 8 GB’a çıkardık, marjinal maliyet ama build ve test adımları yüzde 30 hızlandı.
Adım 6: Artifact önbellekleme (kazanım: 30 saniye)
Node modüller ve composer paketleri her job için yeniden çıkarılıyordu. GitLab cache ile node_modules ve vendor klasörlerini paket lock hash’iyle cache’ledik. İlgili job’lar cache’i restore edip çalışıyor.
Adım 7: Deploy kalite adımı paralel (kazanım: 1 dakika)
Deploy sonrası bir smoke test çalışıyordu. Deploy ve smoke test sıralıydı, smoke test 1 dakika. Deploy’dan sonra deploy’un bitişini beklemeden canary health check’leri başlattık. Smoke test asenkron paralel koştu, deploy bittiğinde zaten test geçmiş oldu.
Son durum
- Lint: 30 saniye
- Unit test: 2 dakika
- Integration test: 3 dakika (paralelde)
- Build: 30 saniye
- Deploy + smoke: 2 dakika (paralelde)
- Total critical path: ~4 dakika
Pipeline dakikaları düştü ama daha önemlisi geliştirici akışı düzeldi. “Build bekliyorum” kaybı yüzde 70 azaldı.
Dikkat edilecek tuzaklar
- Test paralelleştirirken shared state bulmak şart. Aynı veritabanına paralel yazan testler flaky hale geldi. Namespacing, her worker’a farklı schema.
- Cache key’lerini doğru tanımlayın. Yanlış key ile cache temizlenmiyor, bozuk cache ile saatler harcarsınız.
- Incremental lint ana branch ile senkron olmalı. Diff base’i doğru ayarlayın.
- Runner yükseltmesi maliyet getirir, faydasını ölç.
- Snapshot image’ları versiyonla, schema değişirse snapshot’u yenileyin.
Pipeline hızı sadece CI maliyeti değil, geliştirici moralidir. Hızlanan her dakika “bu işi bitirme” motivasyonuna yazılıyor.