Küçük ekiplerde staging ortamı: canlının ucuz provası

Staging, canlının birebir kopyası olmak zorunda değil; canlıya çıkacak sürümün aynı artefakt, aynı deploy yolu ve aynı migration ile önceden denendiği yerdir. Bu yazıda 3–20 kişilik ekipler için abartısız bir staging düzeni öneriyoruz: neyi canlıya benzet, neyi bilerek ayır, maliyeti nasıl makul tut.

Küçük ekiplerde staging genelde iki uçta kalır. Ya hiç yoktur ve her sürüm doğrudan canlıda denenir, ya da bir zamanlar kurulmuş, aylardır güncellenmemiş, kimsenin güvenmediği bir sunucu olarak durur. İkisi de aynı sonuca çıkar: sorunlar müşteriden önce görülmez.

TW Bilişim olarak yazılım ve altyapı işlerinde gördüğümüz tablo: canlıdaki hataların büyük kısmı koddan değil, ortam farkından çıkar. Eksik bir ortam değişkeni, geri dönüşü olmayan bir migration, farklı bir servis sürümü ya da test edilmemiş bir entegrasyon.

Staging neyi yakalar, neyi yakalamaz?

Staging'in işi birim testlerinin yapamadığını yapmaktır:

• Deploy sürecinin kendisi: Image build, ortam değişkenleri, sağlık kontrolleri, sıfır kesintili geçiş.
• Veritabanı migration'ları: Gerçeğe yakın veri hacminde ne kadar sürdüğü, kilit (lock) yaratıp yaratmadığı, geri alınıp alınamayacağı.
• Entegrasyonlar: Ödeme, e-posta, SMS, harici API'ler ve webhook'ların uçtan uca akışı.
• Yapılandırma hataları: Yanlış URL, eksik secret, CORS, sertifika, dosya izinleri.

Staging'in yakalayamadıkları da vardır: gerçek trafik yükü, gerçek kullanıcı davranışı ve canlıya özgü veri tuhaflıkları. Bunlar için gözlemlenebilirlik ve kademeli yayın gerekir; staging bunların yerine geçmez.

Neyi canlıya benzetin?

Benzerlik her şeyde değil, hatanın çıktığı yerlerde gereklidir:

1. Aynı artefakt: Staging'de denenen image ya da paket, canlıya çıkan ile birebir aynı olmalıdır. Canlı için yeniden build almak, staging testini anlamsızlaştırır.
2. Aynı deploy yolu: Staging'e elle kopyalayıp canlıya pipeline ile çıkmak, iki farklı süreci test etmek demektir. İkisi de aynı pipeline'dan geçmelidir.
3. Aynı servis sürümleri: Veritabanı, cache, kuyruk ve runtime'ın ana sürümleri eşleşmelidir. PostgreSQL'in farklı ana sürümleri gibi farklar staging'de görünmeyen hataları canlıya taşır.
4. Aynı migration akışı: Migration'lar staging'de canlıdaki sırayla ve aynı araçla çalışmalıdır.

Bu yaklaşımın temeli CI/CD yazımızdaki “bir kez build et, her yere aynısını dağıt” ilkesidir.

Neyi bilerek ayırın?

Bazı şeyler canlıya benzememelidir:

Konu	Staging'de	Neden
Secret ve anahtarlar	Ayrı değerler	Staging sızıntısı canlıyı açmamalı
Veri	Anonim / sentetik	KVKK ve gizlilik
Ödeme	Sağlayıcının test modu	Gerçek para hareketi olmaz
E-posta / SMS	Yakalayıcı veya izinli liste	Müşteriye yanlışlıkla mesaj gitmez
Boyut	Küçük instance	Maliyet
Erişim	Parola veya VPN arkasında	Arama motoru ve meraklılar

Secret'ların ayrı tutulması kritik; staging çoğu zaman daha gevşek korunur. Bu konuyu secret ve erişim yönetimi yazımızda ayrıntılı anlattık.

Staging verisi: en çok ihmal edilen kısım

Boş bir veritabanıyla yapılan test, “ekran açılıyor” testinden ibarettir. Öte yandan canlı veriyi olduğu gibi staging'e kopyalamak hem gizlilik riski hem de yasal risktir.

Pratik seçenekler:

• Seed verisi: Uygulamanın tüm ana akışlarını kapsayan, sürümle birlikte güncellenen bir örnek veri seti.
• Anonimleştirilmiş kopya: Canlı verinin ad, telefon, e-posta, adres gibi alanları maskelenmiş kopyası. Maskeleme betiği de kod gibi gözden geçirilmelidir.
• Hacim testi için sentetik veri: Migration süresini ölçmek için canlıya yakın satır sayısında üretilmiş veri.

Anonimleştirilmiş kopya alıyorsanız, bu işi düzenli yedekleme akışına bağlamak geri yükleme testini de beraberinde getirir: yedeği staging'e açmak, iki işi tek adımda yapar.

Kalıcı staging mi, geçici önizleme ortamı mı?

İki yaygın model var:

• Kalıcı staging: Her zaman açık tek bir ortam. Kurması basit, ama birden fazla dal aynı anda test edilmek istendiğinde sıra oluşur.
• Geçici önizleme (preview) ortamları: Her pull request için otomatik açılıp kapanan ortamlar. Ürün ve tasarım geri bildirimini hızlandırır, ama otomasyon ve veri hazırlığı gerektirir.

Küçük ekip için öneri: önce tek bir kalıcı staging ile başlayın. Önizleme ortamları, PR sayısı ve ekip büyüdükçe gerçek bir darboğazı çözdüğünde eklenmelidir.

Maliyeti makul tutmak

• Staging'i canlının en küçük işe yarar boyutunda çalıştırın; performans testi ayrı bir iştir.
• Mesai dışında otomatik kapatma, bulut maliyetini ciddi oranda düşürür.
• Yönetilen veritabanı yerine aynı sürümde konteyner veritabanı, staging için çoğu zaman yeterlidir.
• Kullanılmayan önizleme ortamlarını otomatik silin; unutulan ortamlar faturada görünür.

Staging'den canlıya: kısa bir kontrol listesi

Her sürümde aynı birkaç adım:

1. Pipeline aynı artefaktı staging'e çıkardı mı?
2. Migration'lar staging'de sorunsuz ve makul sürede çalıştı mı?
3. Ana akışlar (giriş, ödeme, kritik form, rapor) elle veya otomatik smoke testle doğrulandı mı?
4. Entegrasyon logları temiz mi?
5. Geri alma (rollback) yolu belli mi?

Bu beş madde birkaç dakika sürer; canlıda yaşanacak bir kesintiden çok daha ucuzdur.

Pratik checklist

Madde	Net mi?	Not
Staging ve canlı aynı artefaktı kullanıyor	☐	Yeniden build yok
Deploy aynı pipeline'dan	☐	Elle kopya yok
Servis ana sürümleri eşleşiyor	☐	DB, cache, runtime
Secret'lar ayrı	☐	Canlı anahtarı yok
Veri anonim veya sentetik	☐	KVKK
E-posta / SMS / ödeme test modunda	☐	Müşteriye gitmez
Erişim kısıtlı	☐	Parola / VPN, noindex
Sahibi ve güncelleme ritmi belli	☐	Bayat staging olmaz

SSS

Staging olmadan canlıya çıkmak hiç mi kabul edilemez?
Çok küçük ve düşük riskli projelerde iyi testler, feature flag ve hızlı geri alma ile idare edilebilir. Ancak migration ve entegrasyon içeren her üründe staging maliyetini fazlasıyla geri öder.

Staging canlıdan geri kalıyor, ne yapmalı?
Staging'i her canlı sürümünden önce zorunlu adım yapın. Pipeline staging'den geçmeden canlıya çıkamıyorsa ortam kendiliğinden güncel kalır.

Staging'de canlı veri kullanmak yasak mı?
Bu yazı hukuk metni değil; kişisel veri için KVKK süreçleri ayrıca değerlendirilmelidir. Teknik olarak öneri nettir: kişisel alanları maskelenmemiş canlı veri staging'e taşınmamalıdır.

Staging ile test ortamı aynı şey mi?
Küçük ekiplerde çoğu zaman tek ortam iki işi görür. Ayrım gerekiyorsa: test ortamı geliştiricilerin serbestçe bozduğu yer, staging ise canlıya çıkacak sürümün son provasıdır.

TW Bilişim bu konuda ne yapıyor?
Mevcut altyapınıza uygun, abartısız bir staging ve deploy akışı kuruyoruz: aynı artefakt, aynı pipeline, ayrılmış secret ve veri, makul maliyet. Amaç canlıya her çıkışı sıradan bir iş haline getirmek.

Sonuç

Sıra basit: aynı artefaktı → aynı pipeline ile → aynı migration akışıyla staging'e çıkarın; secret, veri ve dış servisleri bilerek ayırın; maliyeti küçük boyut ve otomatik kapatmayla tutun; her sürümde beş maddelik kontrolü yapın. Staging'in değeri kopyalamaktan değil, canlıdan önce aynı süreci denemekten gelir.

Staging ve deploy akışınızı birlikte sadeleştirmek isterseniz: iletişim veya [email protected].