Bize Yalan Söyleyen CI/CD Hattı: Bir Dağıtım Hata Ayıklama Hikayesi

Geliştirme ortamında kusursuz görünen ancak gerçekte çalışmayan süreçler, yazılım ekiplerinin en sık karşılaştığı sessiz tehlikelerdendir. Bir depoda haftalardır tamamen yapılandırılmış bekleyen bir GitHub Actions iş akışı düşünün: SSH adımları, sunucu anahtarları ve dağıtım tanımları eksiksizdi. Buna rağmen arka uçta yapılan her güncellemede sunucuya elle SSH ile bağlanıp git pull çalıştırmak gerekiyordu. Sorun büyük bir sistem çöküşü değil; birbiri ardına sıralanmış, her biri bir sonrakini gizleyen küçük hatalar silsilesiydi.

Perde 1: Hiç Çalışmayan Dağıtım İşi (Act 1)

deploy.yml dosyasındaki dağıtım adımı mantıksal olarak doğru kurulmuştu: Yalnızca main dalındaki CI iş akışı başarıyla (success) tamamlandığında dağıtım tetiklenecekti. Ancak GitHub CLI (gh run list) ile geçmiş sorgulandığında çarpıcı bir gerçek görüldü: CI akışı main dalında hiçbir zaman başarılı olmamıştı ve bu yüzden tüm dağıtım adımları otomatik olarak atlanıyordu (skipped). Dağıtım mekanizması bozuk değildi; sadece kendisine verilen görevi yapıyor ve asla yeşile dönmeyen bir CI sürecini bekliyordu. Dağıtım ve test süreçlerinin arayüzde farklı sekmelerde bulunması ise bu bağlantının fark edilmesini haftalarca geciktirmişti.

• Pratik Çıkarım: Bağımlı (gated) iş akışlarında dağıtım mekanizmasından şüphelenmeden önce, tetikleyiciyi besleyen öncül testlerin geçmişi doğrulanmalıdır.

Perde 2: Aynı Pardösüyü Giyen İki Hata (Act 2)

Çalıştırma kayıtları incelendiğinde, test edilen kodla hiçbir ilgisi olmayan iki altyapı hatası ortaya çıktı:

• Linter ve .gitignore Uyuşmazlığı: Linter adımı .python-version dosyasının eksikliği nedeniyle anında sonlanıyordu. Dosya yerel geliştirme ortamında bulunuyordu ancak eski bir yapılandırmadan kalan .gitignore kuralı nedeniyle repoya eklenmemişti. actions/setup-python eylemi dosyanın repoda fiziksel olarak var olmasını şart koşar.
• Frontend ve Node Sürüm Uyumsuzluğu: ci.yml dosyasında Node 20 sürümü sabitlenmişti. Oysa Vitest bağımlılığı olan jsdom@30, Node 22+ gerektiriyordu. Node 20'de markAsUncloneable fonksiyonu bulunmadığı için frontend testleri başlamadan çöküyordu.

Asıl arka uç testleri (pytest) sorunsuz geçtiği halde bu iki altyapı pürüzü tüm süreci kilitliyordu. Çözüm; .python-version dosyasını repoya eklemek ve Node sürümünü 22'ye yükseltmek oldu. İki satırlık değişiklik iki kök nedeni ortadan kaldırdı.

• Pratik Çıkarım: Yerelde çalışan bir dosyanın CI'da bulunamaması çoğunlukla gözden kaçan .gitignore kurallarındandır. Ayrıca paket bağımlılıklarının çalışma zamanı (engines) gereksinimleri ile CI ortamı senkronize edilmelidir.

Perde 3: Hep Orada Olan Teknik Borç (Act 3)

Altyapı düzeltmelerinin ardından pytest ve frontend testleri başarıyla tamamlandı. Ancak bu kez linter, kod biçimlendirme araçları (black ve isort) nedeniyle yeniden hata verdi. Önceki altyapı çökmeleri nedeniyle hiç çalıştırılamayan bu kontroller, kod tabanında sessizce biriken biçimlendirme borcunu gün yüzüne çıkardı.

• Pratik Çıkarım: Hata ayıklama katmanlı bir süreçtir; altyapı sorunları çözüldükçe gizlenmiş teknik borçlar açığa çıkar.

Orijinal kaynağa buradan ulaşabilirsiniz.