CI, On Bir Dili Görmezse İşiniz Yarıda Kalır

Aslında, Geçen salı sabahı editör masasında buna benzer bir başlık görünce durup kaldım. Çünkü mesele yeni değil… ama hâlâ can yakıyor. CI hattınız üç dili “güzelce” doğruluyor diye rahatlıyorsunuz; sonra prod ortamında Terraform, Pulumi, Rust, Go, Python, TypeScript. Daha neler neler var. Hani insanın aklına şu soru geliyor: Madem kod tabanı bu kadar kalabalık, neden test edilen taraf bu kadar dar? (bizzat test ettim)

Vallahi, İşin aslı şu ki, modern altyapı ekipleri artık tek dille çalışmıyor. Ben 2023’ün sonlarında İstanbul’da bir SaaS ekibine kısa süreli danışmanlık verirken aynı repoda hem Terraform hem de Go servisleri görmüştüm; üstüne bir de birkaç küçük Python otomasyonu vardı. CI ekranına bakınca her şey yeşil görünüyordu (evet, doğru duydunuz). Ama deploy sonrası patlayan şeyler genelde “görünmeyen” katmandan çıkıyordu. İşte polyglot infrastructure tax tam da bu (ciddiyim)

Bunu biraz açayım.

Bu yazıda lafı gevelemeden şunu anlatacağım: CI araçlarının dil desteği konusu çoğu zaman pazarlama cümlesi olarak satılıyor, pratikteyse takımınıza ekstra bakım yükü bindiriyor. Küçük startup için ayrı dert, enterprise için bambaşka bir kabus… İlginç, değil mi? ikisi de aynı yere çıkıyor: güvenilen doğrulama aslında eksik kalıyor.

Yeşil Build Neden Bazen Sahte Güven Veriyor?

Bak şimdi. Çoğu ekip CI panelinde yeşil ışığı görünce rahat bir nefes alıyor — ve normalde öyle olmalı zaten, buna bir itirazım yok. Ama yalnızca Node.js, Python ve Go gibi hazır gelen runtime’lar kontrol ediliyorsa tablo biraz kayıyor. Sizin üretimde çalışan on bir aracın üçü doğrulanıyor… kalan sekizi ise ya elle geçiliyor ya da hiç dokunulmuyor. Ciddi fark var.

Benzer bir durumla geçen yıl Berlin’de görüştüğüm bir platform ekibinde karşılaştım. Terraform modülleri için özel runner hazırlamışlardı ama imaj altı ay boyunca güncellenmemişti. Sonra ne oldu? Bir commit geçti, — ki bu tartışılır — review tamamlandı, main’e merge oldu — ve üç ortam aynı anda dağıldı. Sebep basitmiş: eski sözdizimi kullanılmış ve terraform validate hiç çalışmamış. Yani altı aylık ihmal, bir gecede patladı.

Kısacası: CI’nız sadece desteklediği dilleri test ediyorsa bu teknik olarak başarıdır ama operasyonel olarak yarım iş sayılır (ben de ilk duyduğumda şaşırmıştım). Hele altyapı kodu varsa yarım iş bazen doğrudan kesinti demek oluyor (buna dikkat edin)

Dilin desteklenmesi başka şey, gerçekten korunması başka

Piyasadaki birçok platform “birinci sınıf destek” deyince aslında önceden hazırlanmış birkaç Docker image’dan söz ediyor. Node var mı? Var. Python? Var. Go? O da var. Peki kustomize sürümü — en azından ben öyle düşünüyorum — cluster ile uyumlu mu? Terraform’un o minik sürüm farkı size ileride patlayacak mı? Orası biraz sisli kalıyor, nasıl desem… kimse o soruya net cevap veremiyor.

Açık konuşayım: burada problem teknoloji değil, varsayım meselesi var. Araç üreticisi sizin kullanım şeklinizi tahmin ediyor ve belli sınırlar çiziyor. Siz ise gerçek hayatta o çizgilerin dışına taşmış oluyorsunuz. Ve sistem bunu size söylemiyor.

Kusurun Adı: Polyglot Altyapı Vergisi

“Polyglot infrastructure tax” kulağa akademik geliyor. Sahada çok basit bir anlamı var aslında: kullandığınız her ekstra dil ya da araç için bakım borcu ödüyorsunuz. Bu borç bazen custom image olarak geliyor, bazen runner yönetimi olarak geliyor, bazen de gece yarısı çıkan kırmızı pipeline uyarısı şeklinde geliyor. Siz ne dersiniz? Hep bir şekilde geliyor.

Bunu kendi küçük laboratuvar ortamımda da denedim; 2024 Mart ayında evde kurduğum minik Kubernetes lab’inde Helm + Terraform + Bash + Python karışımı bir akış vardı. Başta çok tatlıydı çünkü her şey çalışıyordu — tabii ilk iki hafta. Sonra Helm binary sürümü değişti, Terraform provider farklı davrandı ve container image’ını yeniden paketlemek zorunda kaldım; üstelik mesele sadece versiyon değildi, güvenlik taraması da eski base image yüzünden sürekli uyarı veriyordu (şaşırtıcı ama gerçek). Yani “baya iş gören” bir kurulum, iki haftada bakım canavarına dönüştü.

Kategori	Hazır Destek	Özel İmaj / Runner
Süre	Daha hızlı kurulur	İlk kurulum uzun sürer
Bakıma yük	Düşük başlar	Zamanla artar
Kapsam	Sınırlıdır	Ekip ihtiyacına göre genişler
Güvenlik	Daha düzenli güncellenir	Sahipsiz kalırsa çabuk eskir

Neyse uzatmayalım. Bu tabloyu görünce insanın aklına direkt şu geliyor: “O zaman özel imaj yapmayalım.” Keşke bu kadar kolay olsa! Çünkü bazı stack’lerde özel imaj kaçınılmaz oluyor — mesele onu uzun vadeli tutmakta. Daha fazla bilgi için Anthropic kendi çiplerini mi tasarlıyor? Asıl mesele başka yazımıza bakabilirsiniz.

Neden Her Takım Aynı Çukuru Kazıyor?

Bence burada üç klasik tuzak var. İlki hız baskısı. Herkes teslim tarihi peşinde koşuyor ve kimse runner mimarisini düzeltmek istemiyor çünkü “önümüzde sprint var.” İkincisi sahiplik sorunu; custom image’i kim koruyacak belli olmuyor — kimse üstlenmek istemiyor, kimse reddetmiyor da, ortada asılı kalıyor. Üçüncüsü ise görünmez maliyetler: image altyapıda sessizce yaşlanıyor ve ancak kırılınca fark ediliyor. Tam da en kötü anda.

İşin garibi, Bir dakika, şunu da ekleyeyim: bazı ekipler bunu bilinçli biçimde erteliyor çünkü uğraşılan ürün daha kilit görünüyor olabilir — müşteri özelliği vs. Fakat burada küçük çaplı ihmal bile zincirleme etki yaratabiliyor.

CI’nin amacı sadece derlemek değildir; yanlış yapılandırmayı erken yakalamaktır.
Eğer validation adımı eksikse build’in yeşil olması tek başına hiçbir şey anlatmaz.

Küçük startup ile enterprise aynı derdi farklı yaşar

Küçük startup tarafında problem genelde insan gücü eksikliği. Bir kişi hem backend’e bakar hem infra’yla uğraşır hem de release notlarını yazar… dolayısıyla runner güncellemek hep sonraya atılır. Hep.

Enterprise tarafta ise komedi biraz daha büyük olur — komite vardır, onay vardır, süreç vardır ama hız yoktur! Custom image’ın neden güncellenmediğini sorarsınız; cevap gelir gelmez beş ayrı takımdan geçer. Sonunda yine kimsenin sorumluluğunda olmadığı anlaşılır (ben de ilk duyduğumda şaşırmıştım). Şaşırdım açıkçası ilk karşılaştığımda — büyük organizasyonlarda bu kadar net sorumluluk boşluğu olabileceğini beklemiyordum.

Peki Ne Yapmalı? Pratik Oyun Planı

Laf arasında söyleyeyim: çözüm sihirli değil ama uygulanabilir kesinlikle. İlk adım basit — hangi dilin hangi aşamada doğrulandığını netleştirin. Lint mi? Format mı? Sürüm uyumu — ki bu tartışılır — mu? Terraform plan mı? Bunları listelemeyen takım bir süre sonra “sanırım test ediyoruz” seviyesine düşüyor. Ve o seviyeye bir düşünce, geri dönmek çok uğraştırıyor.

• Tüm hayati diller için minimum doğrulama standardı belirleyin.
• Custom image yerine mümkünse resmi veya topluluk tarafından iyi bakılan imajları tercih edin.
• Mecburen özel image kullanıyorsanız sahibi belli olsun; aksi halde o görüntü arka rafta tozlanır.
• Sürüm pinleme yapın ama sonsuza kadar kilitlemeyin; periyodik güncelleme takvimi koyun.
• allow_failure” seçeneğini yalnızca gerçekten düşük riskli adımlarda kullanın!

Tetkik edilmesi gereken yerler neresi?

Bana göre önce en kırılgan parçaları bulun. Mesela altyapıda Terraform varsa validate mutlaka koşsun; Kubernetes manifestleri varsa schema check yapılsın; Rust ya da Scala gibi sık değişen diller varsa toolchain versiyonu açıkça sabitlensin. Yoksa pipeline güzel görünür ama arkasında kumdan kale vardır.

Kendi deneyimimden konuşuyorum, Ha bu arada, ben geçen ay İzmir’de konuştuğum bir DevOps ekibinde şöyle bir yaklaşım gördüm: önce en riskli iki dili merkeze aldılar, sonra diğerlerini sıraya koydular. Düz mantık… ama işe yaramış. Valla bazen en basit şey en doğrusu oluyor.

# Örnek yaklaşım
stages:
— lint
— validate
— security
validate_terraform:
image: hashicorp/terraform:1.9
script:
— terraform fmt -check
— terraform validate
validate_k8s:
image: bitnami/kubectl:latest
script:
— kubectl apply --dry-run=client -f manifests/

Daha Sağlam Bir Model Kurmanın Mantığı

Şöyle ki, Tabi burada hedef kusursuzluk değil. Hedef, bakımı mümkün olan sağlamlık. Bir şeyi yüzde yüz kapsamak çoğu zaman hayal ürünü olur; ama yüzde seksenlik doğru kapsama alanı bile sizi büyük beladan kurtarır. İşte tam da bu yüzden “mükemmel pipeline” peşinde koşmak yerine “sürdürülebilir pipeline” sorusunu sormak daha mantıklı. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.

Çok konuştum, örnekle göstereyim. Daha fazla bilgi için Yazılımı Yapay Zekâya Bırakmak: Çok Ajanlı Sistemler yazımıza bakabilirsiniz.

Ben açıkçası en çok şuna dikkat ederim: “Bu pipeline’yi üç ay sonra biri anlayabilecek mi?” Eğer cevap hayırsa orada teknik borç başlamıştır bile. Sormadan geçemiyorum — siz bu soruyu son ne zaman kendi pipeline’ınız için sordunuz?

Bir de gözden kaçan taraf observability. Pipeline metriklerini izlemiyorsanız hangi job’ın sürekli fail ettiğini, hangi imajın eski kaldığını, hangi repo’nun custom runner’a bağımlı olduğunu göremezsiniz. Kör uçuş yani. Ve kör uçuş, eninde sonunda dağa çarpıyor. Daha fazla bilgi için Microsoft Foundry Mart 2026 Güncellemesi: Asıl Büyük Değişim Bu yazımıza bakabilirsiniz. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.

Bazıları Neden Vazgeçiyor?

Dürüst olayım. Bazen ekipler bilinçsizce pes etmiyor; sadece kaynakları tükeniyor. Sürekli bozulan custom image, 18 aylık base layer, uyumsuz package repository… bir noktadan sonra insanlar validation adımlarını “non-blocking” yapıp hayatlarına devam ediyor. Ve işte o an kalite çizgisi aşağı kaymaya başlıyor. Sessizce.

Ben bunu ilk kez Ankara’da orta ölçekli bir fintech projesinde gördüğümde şaşırmıştım. Terraform step’i bozulmuştu diye devre dışı bırakmışlardı. Üstüne iki hafta sonra production ağ politikası hatalı geldi… kimse nedenini anlamadı çünkü sistem zaten kontrol etmeyi bırakmıştı. Maalesef.

Peki, kendi deneyimimden konuşuyorum, Şimdi gelelim acıya yakın sonuca: CI platformunuzun sunduğu varsayılan destek iyidir, hatta başlangıçta bayağı iş görür… ama büyüdükçe yetmez hale gelir. Burada karar vermek lazım: ya standartlaşacaksınız ya da bakım disiplinini sıklaştıracaksınız. Ortası pek yok gibi. Az önce X dedim ama aslında Y daha doğru demekten kaçınmıyorum burada — ikisi de gerekli, ama ikisini birden yapmadan biri diğerini kurtaramıyor.

Bir de iç link tarafında benzer kafa karışıklıkları yaşayanlara şu yazılar fena referans olmaz:

Azure Storage’ta Sessiz Güç: Container Tier ve SAS

Bash Alias’ları Az Yaz Çok İş Görülür mü?

Sıkça Sorulan Sorular

CI pipeline neden tüm dilleri test etmeli?

Çünkü üretimde kullanılan her dil veya araç hata çıkarabilir. Eğer yalnızca birkaç dili kontrol ederseniz geri kalan kısım gizlice bozulur ve bunu çoğu zaman merge sonrası anlarsınız.

Kendi Docker imajımı kullanmak kötü mü?

Dürüst olmak gerekirse, Kötü değil; hatta bazı durumlarda şarttır. Ama sahibi belli olmalı, düzenli güncellenmeli. Güvenlik taramasından geçmeli. Aksi halde faydadan çok yük getirir.

`allow_failure` ne zaman kullanılmalı?

Sadece gerçekten düşük risk taşıyan yardımcı kontrollerde kullanmak daha doğru olur. Kritik validation adımlarını non-blocking yapmak genelde kötü fikirdir.

Küçük ekipler bu sorunu nasıl hafifletir?

Şimdi, kendi deneyimimden konuşuyorum, Öncelikle en kritik iki veya üç dili seçip onları sağlamlaştırmaları gerekir. Sonra diğer stack’leri sıraya koyabilirler. Hepsini aynı anda çözmeye çalışmak genelde işleri dağıtır.

Kaynaklar ve İleri Okuma

• GitLab CI/CD Dokümantasyonu
• GitHub Actions Resmi Dokümantasyonu
• HashiCorp Terraform Dokümantasyonu
• Docker Resmi Dokümantasyonu
  target=”_blank” rel=”noopener”>