Bakın şimdi, Kubernetes tarafında en çok vakit yediren şey bazen kodun kendisi olmuyor… paylaşılan staging ortamı oluyor. Her ekip oraya bir şey bırakıyor, biri veritabanını şişiriyor, diğeri konfigürasyonu değiştiriyor, üçüncü kişi de “bende çalışıyordu” diye dolaşıyor. Sonra da test sonuçlarına bakıp güvenmeye çalışıyoruz. Açık konuşayım — bu biraz sisli havada araba sürmeye benziyor. Göremiyorsunuz, ama ilerliyorsunuz.
Benzer bir sıkışmayı 2024 Şubat’ında İstanbul’daki bir fintech ekibinde birebir gördüm. Beş mikroservis tek namespace üstünde yarışıyordu ve her PR sonrası testler ya bekliyordu ya da sebepsiz yere patlıyordu. En sinir bozucu kısım neydi biliyor musunuz? Hata çoğu zaman kodda değildi. Komşu servisin bıraktığı artık durumda çıkıyordu — o meşhur “bende yeşildi” anı. İşin aslı şu ki, staging ortak alan olunca kalite kapıdan içeri zor giriyor, hani ciddi söylüyorum.
Bir dakika — bununla bitmedi.
Size bir şey söyleyeyim, Şimdi gelelim çözüm tarafına. Shift-left yaklaşımı burada sadece “unit testleri erkene çekelim” demek değil — bayağı daha geniş bir şey aslında (en azından benim deneyimim böyle). Ortam yaşam döngüsünü de CI akışının içine alıyorsunuz; yani her pull request için kısa ömürlü, tertemiz bir Kubernetes namespace açılıyor, test bitti mi siliniyor, kir yok, eski veri yok, komşu takımın bıraktığı sürpriz yok. Kulağa basit geliyor. Değil tabii.
Neden Paylaşılan Staging Artık Yeterli Değil?
Paylaşılan staging’in temel sorunu basit aslında. Herkes aynı mutfakta yemek yapmaya çalışıyor ama tek ocak var. Bir ekip cache temizliyor, öbürü migration atıyor, üçüncüsü seed data basıyor… derken kimin neyi bozduğunu anlamak zorlaşıyor, neredeyse imkânsız hale geliyor. Bu yüzden “flaky test” dediğimiz o meşhur hayaletler ortaya çıkıyor — bir gün yeşil olan pipeline ertesi gün kırmızıya dönüyor ve kimse tam emin olamıyor. Kimse.
Bunu biraz açayım.
Geçen yaz Berlin’de katıldığım küçük bir bulut etkinliğinde bir platform mühendisi aynen şunu söylemişti: “Staging’i debug etmek için iki kişi ayırıyoruz.” Bu cümle kulağa komik geliyor. Maliyet kısmı hiç komik değil ama. Çünkü asıl kayıp yalnızca zaman değil; karar kalitesi de düşüyor, ekipler hatalı sinyal yüzünden doğru yerde durmak yerine gereksiz yere ileri gidiyor ya da tam tersi, yanlış yerde takılıp kalıyor.
Paylaşılan staging ortamı büyüdükçe görünürlük azalır; görünürlük azaldıkça da testler güven vermekten çok gürültü üretir.
Bu noktada shift-left yaklaşımı devreye giriyor ama laf olsun diye değil. Mantık şu: testi prod’a yakınlaştırmak yetmiyor, ortamı da erken aşamaya taşımanız gerekiyor. PR daha merge edilmeden kendi gerçek dünyasına benzer mini evreninde koşuyor böylece (en azından benim deneyimim böyle). Fark var mı? Var. Ciddi fark.
Kubernetes Test Piramidini Yeniden Düşünmek
Araya gireyim: Klasik test piramidini hepimiz biliriz. Altta unit testler, ortada integration testler, tepede birkaç uçtan uca senaryo (ben de ilk duyduğumda şaşırmıştım) (eh, fena değil). Kubernetes dünyasında bu piramit biraz şekil değiştiriyor — çünkü artık mesele yalnızca uygulama kodu değil. Ağ politikası var, secret yönetimi var, ingress davranışı var, hatta bazen DNS bile trip atabiliyor. Evet, DNS. O kadar.
Kendi deneyimimde en çok faydayı veren yaklaşım şu oldu: unit testleri runner içinde tutmak, bağımlılıkları container düzeyinde simüle etmek. Gerçek orkestrasyon kontrolünü ephemeral namespace’e bırakmak. Mesela PostgreSQL veya Redis’i Testcontainers ile ayağa kaldırıp uygulamanın mantığını hızlıca doğruluyorsunuz; ardından Kubernetes tarafında deploy davranışını izliyorsunuz, hata nerede çıktıysa orada görüyorsunuz — tahmin yürütmüyorsunuz, bakıyorsunuz. Fark işte bu.
| Katman | Amaç | Süre | Risk |
|---|---|---|---|
| Unit Test | Lojik doğrulama | Çok kısa | Düşük |
| Container Integration | Bağımlılıkları sınama | Kısa-orta | Orta |
| Ephemeral Namespace | Tam akışı doğrulama | Orta | Daha düşük sürpriz riski |
| Production Smoke Testi | Sınırlı canlı doğrulama | Kısa | Düşük ama kritik |
Neyi nereye koymalı?
Bence en sağlıklı düzen şu sırayı izliyor: önce hızlı unit testler, sonra container tabanlı entegrasyon kontrolleri, ardından her PR için ayrı namespace içinde çalışan ephemeral ortamlar ve en sonda prod’da küçük smoke testleri. E peki, sonuç ne oldu? Bu zinciri kurunca ekiplerin birbirine bağımlılığı azalıyor — herkes kendi şeridinde koşuyor, yani. Bu konuyla ilgili Cantor Fitzgerald Neden Robinhood ve Coinbase’i Seçiyor? yazımıza da göz atmanızı tavsiye ederim.
E tabi burada kritik nokta hız ile temizlik arasında denge kurmak. Eğer ephemeral environment hazırlığı beş dakika sürüyorsa. Pipeline toplam süresini uzatıyorsa herkes burun kıvırır, haklı da olur. Ama altyapıyı iyi kurarsanız sonuç bayağı tatmin edici oluyor; özellikle karmaşık mikroservis sistemlerinde, bunu söyleyebilirim.
Geçici Namespace Nasıl Kurulur?
Lafı gevelemeden söyleyeyim: temel fikir her PR için benzersiz bir namespace oluşturmak ve deploy’u oraya yapmak. İş bittiğinde namespace’i temizlemek gerekiyor ki hem kaynak boşa gitmesin hem de cluster çöplüğe dönmesin. İlginç, değil mi? Küçük startup’larda bunu GitHub Actions + Helm ile rahatça halledebilirsiniz; enterprise tarafta ise policy’ler ve quota yönetimi devreye girer, işler biraz daha karmaşıklaşır. Daha fazla bilgi için Premium SaaS Landing Page: Tailwind ile Hızlı Kurulum yazımıza bakabilirsiniz. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
apiVersion: v1
kind: Namespace
metadata:
name: pr-1247-preview
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 1
template:
spec:
containers:
— name: api
image: registry.example.com/api:${GIT_SHA}İlginç olan şu ki, Böyle bir yapı kurarken isimlendirme standardı önemli olur; yoksa yarın sabah cluster’da on farklı preview namespace görüp hangisinin kime ait olduğunu anlayamazsınız. Başımıza geldi bu arada, güldürmüyor. Ben Mart 2025’te Ankara’da yaptığım bir PoC’de bunu ilk elden yaşadım ve açıkçası temizlik otomasyonu yoksa iş biraz çorba oluyor — “biraz” derken çok çorba oluyor yani (yanlış duymadınız) Bu konuyla ilgili Lucid, Uber’in Robotaksi Hamlesi ve Yeni CEO: Ne Değişiyor? yazımıza da göz atmanızı tavsiye ederim.
Tear-down neden şart?
Tear-down, yani kapatma adımı, çoğu ekipte üvey evlat muamelesi görüyor. Bence asıl kahraman orasıdır. Namespace silinmezse maliyet artar, stateful resource’lar ortalıkta kalır, bir de üstüne yanlışlıkla prod sanılan preview servisleri çıkar — kısacası temizlik yoksa otomasyon yarım kalır, nokta.
Bir arkadaşım Londra’daki SaaS şirketinde bunu ihmal etmişti; iki ay sonunda boş duran PVC’ler yüzünden fatura %18 yükselmişti. İnanılmaz mı? Değil. Sadece unutulmuştu. Eğer altyapınız GitOps mantığıyla ilerliyorsa bu iş daha da rahatlar çünkü manifest değişikliğiyle birlikte geçici ortamların yaşam döngüsünü de versiyonlarsınız. Güzel özellik. Gel gelelim burada dikkat edilmesi gereken şeylerden biri RBAC’tir — her geliştiricinin sınırsız erişimi olması gerekmez, hatta olmamalıdır. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
Sorunsuz Veri Yönetimi İçin Küçük Hileler
Evet, asıl can sıkıcı noktalardan biri veridir. Uygulamayı ayağa kaldırmak kolaydır (buna dikkat edin). Gerçekçi veri seti olmadan testlerin pek anlamı kalmaz — boş tabloyla koşan entegrasyon testi size huzur verir, ama çok az şey öğretir. Aldatıcı bir huzur bu.
Ben genelde üç katmanlı yaklaşımı seviyorum: seed data, anonimleştirilmiş örnek kayıtlar. Gerektiğinde sahte servis cevapları. Böylelikle hem hız kazanırsınız hem de veri bağımlılığını azaltırsınız. Bir de şu var: database migration’larını sadece release anında değil, ephemeral ortamda da denemek lazım. Çünkü kırılan yer çoğu zaman kodun yeni hali değil, eski veriye dokunan migration oluyor — bu konuda %100 emin değilim. Sanırım çoğu ekip hâlâ migration testini son aşamaya bırakıyor, orada patlayınca da gece nöbeti başlıyor. Bu pek eğlenceli değil.
Bir başka pratik yöntem de disposable database kullanmak. Yani PostgreSQL ya da MySQL instance’ını kısa süreli ayağa kaldırıp iş bitince silmek. Kulağa pahalı gelebilir ama iyi kurgulanmış pipeline’da aslında israf etmiyorsunuz; aksine saat bazlı insan emeğini kesiyorsunuz — hangisi daha pahalı, siz karar verin.
Maliyet Kontrolü ve Operasyonel Gerçeklik
Burası önemli çünkü herkes “geçici ortam harika” diyor ama fatura gelince yüz ifadesi değişiyor. Hep böyle. İşte o yüzden kaynak limitleri şart: namespace quota, CPU/memory sınırı, otomatik TTL, gereksiz image cache temizliği… Hepsi birlikte düşünülmeli, tek tek değil.
Küçük bir startup için hedef genelde sade olur: tek cluster, hafif preview stack, ucuz storage, maksimum otomasyon. Enterprise seviyede ise tablo değişir — audit log zorunlu olur, security scan pipeline’a girer, network policy detayı artar, bazense compliance yüzünden approval akışı bile eklenir. Burada güzel olan şey şu: aynı mimari iki farklı ölçekte yaşayabiliyor. Beklediğim kadar kusursuz mu? Hayır. Bilhassa büyük organizasyonda approval zinciri uzarsa ephemeral’in verdiği hız avantajının bir kısmı eriyebilir. Ama yine de shared staging’den iyidir — o kadar net söylüyorum.
- Küçük ekip: Basit Helm chart + otomatik teardown yeterli olabilir. — bunu es geçmeyin
- Büyüyen ürün: Preview env şablonları standartlaştırılmalı.
- Kurum ölçeği: Policy-as-code ve cost guardrail şart hale gelir. — ciddi fark yaratıyor
- Müşteri odaklı SaaS: Her PR’ın etkisini izlemek için metrik toplamak gerekir.
Docker Compose İçin 7 Şablon : Kurulum Kafası Karışmasın
Garip gelecek ama, Ha bu arada bu yazıya bakmanız iyi olabilir; Görsel Testin ROI’si : Yönetime İkna Etmenin Kısa Yolu — özellikle kalite kültürü tarafını düşünüyorsanız. Ve lokal geliştirme akışını toparlamak isteyenlere de Ddev’e Aljibe Eklemek : Kurulu Projede Sürprizler fena gitmez.
Sıkça Sorulan Sorular
Kubernetes’te shift-left testing ne demek?
Kısaca testi üretime yakınlaştırmadan önce sola çekmek demek değildir yalnızca; ortam kurulumunu da erken aşamada CI içine almak demektir.
Ephemeral environment neden daha iyi?
Çünkü her PR için temiz başlangıç verir.
Başka ekiplerin bıraktığı durumdan etkilenmezsiniz ve flaky test sayısı ciddi biçimde düşebilir.
Böyle bir yapı küçük takımda işe yarar mı?
Evet,
hatta bazen en çok küçük takımlarda fark yaratır.
Kurulum basitse hızlı geri dönüş alırsınız;
ama aşırı karmaşıksa ilk etapta sizi yavaşlatabilir.
Maliyet nasıl kontrol edilir?
Tear-down otomasyonu,
namespace quota’su ve TTL politikasıyla.
Silme adımı düzgün kurulmazsa maliyet sessizce büyür;
bu yüzden bunu sonradan eklemeye çalışmayın.
Kaynaklar ve İleri Okuma
Kubernetes Namespaces Resmî DokümantasyonuGitHub Actions Resmî DokümantasyonuTestcontainers Resmî Sitesi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
