Uygulama Geliştirmede Staging: Nedir, Görevleri ve Ortam Kurulumu

Staging Ortamı Nedir

Staging, üretime dağıtımdan önce son doğrulama platformu olarak hizmet veren bir ortamdır. Geliştirme ve test ortamlarının aksine, staging gerçek işletim koşullarına mümkün olduğunca yakındır: aynı işletim sistemi sürümlerini, benzer ağ yapılandırmasını, karşılaştırılabilir veri hacimlerini ve aynı harici entegrasyonları kullanır.

Staging'in temel amacı, yalnızca gerçek işletime yakın koşullarda ortaya çıkan sorunları tespit etmektir. Örneğin, yüksek yük altında yarış koşulları, bağımlılık sürümü uyumsuzlukları ve üretim verileriyle uç durumların hatalı işlenmesi.

Microsoft DevOps Practices, 2025'e göre, staging ortamının düzenli kullanımı, değişiklik başarısızlık oranını (change failure rate) azaltan ilk 5 uygulama arasındadır. Staging aşamasını atlayan ekipler, kritik olaylarla 3-4 kat daha sık karşılaşır.

CI/CD Boru Hattının Bir Parçası Olarak Staging

Olgun bir boru hattında, staging otomatik test aşamasını takip eder ve üretimden önce gelir. Önceki tüm kontrolleri başarıyla geçen bir yapıt, staging'e dağıtılır ve burada uçtan uca senaryolar, yük testleri ve manuel kabul (gerekirse) gerçekleştirilir.

Staging ve Diğer Ortamlar

Geliştirme ortamları arasındaki farkları anlamak, testleri aşamalara doğru şekilde dağıtmaya yardımcı olur. Her ortam kendi amacına hizmet eder ve farklı doğrulama araçları kullanır.

Staging ve QA Ortamı Arasındaki Temel Farklar

Bir QA ortamı genellikle sentetik veri içerir ve mimari açıdan üretimden farklı olabilir (örneğin, daha az veritabanı kopyası). Staging ise tam eşitlik hedefler: aynı hizmet sürümleri, benzer veritabanı ölçeği (veriler anonimleştirilmiş olsa da) ve aynı ağ ortamı.

Staging Ne Zaman Gerekli Değildir

Düşük güvenilirlik gereksinimleri olan basit projeler için ayrı bir staging ortamını sürdürmenin maliyeti haklı çıkmayabilir. Bu gibi durumlarda, üretim benzeri verilere sahip bir QA ortamı staging işlevi görebilir. Ancak yüksek SLA'ya (%99,9+) sahip projeler için staging zorunludur.

Staging'de Ne Test Edilir

Staging ortamı, önceki aşamalarda gerçekleştirilmesi imkansız veya verimsiz olan kontroller için tasarlanmıştır. Her test türü belirli bir kusur kategorisini ortaya çıkarır.

Uçtan Uca (E2E) Testler

Sistemin tüm bileşenlerinden geçen tam kullanıcı senaryoları: mobil uygulama -> API -> veritabanı -> harici hizmetler. Mobil uygulamalar için, E2E testleri kayıt, yetkilendirme, ödemeler ve push bildirimlerini içerir. Araçlar: Detox, Appium, Espresso, XCUITest.

Yük Testi

Staging, gerçekçi yük ile performans testi yapılabilecek tek ortamdır. Kullanılan araçlar: JMeter, k6, Gatling. Amaç, uygulamanın beklenen RPS'yi (saniyedeki istek sayısı) kaldırabildiğini doğrulamak ve önceki sürüme kıyasla performans düşüşünü tespit etmektir.

Gerçek Bağımlılıklarla Entegrasyon Testi

Staging'de hizmetler, mock'larla değil, harici sistemlerin gerçek (veya sandbox) sürümleriyle iletişim kurar. Ödeme ağ geçitleri, e-posta/SMS gönderimi, analitik izleyiciler — tüm entegrasyonlar üretime mümkün olduğunca yakın koşullarda test edilir.

// Staging ortamı için Retrofit yapılandırma örneği
object ApiClient {
    private fun getBaseUrl(): String {
        return when (BuildConfig.FLAVOR) {
            "staging" -> "https://api.staging.example.com/"
            "production" -> "https://api.example.com/"
            else -> "https://api.dev.example.com/"
        }
    }

    val api: ApiService = Retrofit.Builder()
        .baseUrl(getBaseUrl())
        .build()
        .create(ApiService::class.java)
}

Staging'de Veri Yönetimi

Staging'deki veriler, ortam kurulumunun en zorlu yönlerinden biridir. Bir yandan güvenilir testler için üretim verilerine mümkün olduğunca benzemelidir; diğer yandan güvenlik ve gizlilik gereksinimleri karşılanmalıdır.

PII'nin Anonimleştirilmesi ve Maskelenmesi

Kullanıcıların kişisel verileri (e-posta, telefon, adres, ödeme bilgileri) staging'e kopyalanmadan önce anonimleştirilmelidir. Belirleyici şifreleme veya sentetik verilerle değiştirme kullanın. Araçlar: Delphix, Tonic, maskelenmiş değerlerde UPDATE ile özel SQL betikleri. Maskelemenin iş mantığını bozmadığından emin olun — örneğin, e-posta gönderimini test etmek için e-postalar geçerli bir formatta kalmalıdır.

Veritabanı Şeması Senkronizasyonu

Staging veritabanı şeması, migrasyonlarla otomatik olarak güncellenmelidir. Şema sürümlemesi için Liquibase veya Flyway kullanın. Migrasyonlar tüm ortamlara sırayla uygulanır: dev -> QA -> staging -> production. Staging ve üretim arasındaki herhangi bir şema tutarsızlığı, testlerin güvenilirliğini azaltır.

Veri Hacmi ve Performans

Staging'in üretim verilerinin tam hacmini içermesi gerekmez. Performans testleri için, tüm temel senaryoları kapsayan temsili bir örnek yeterlidir. Ancak, ölçekleme sorunlarını belirlemek için veri hacminin minimum test eşiğinden en az 3-5 kat daha büyük olduğundan emin olun. Tam döküm yerine yalnızca ilgili veri alt kümelerini kopyalamak için alt kümeleme (subsetting) kullanın.

# Staging için veri anonimleştirme betiği
import hashlib

def anonymize_email(email):
    local, domain = email.split('@')
    hash_local = hashlib.sha256(local.encode()).hexdigest()[:10]
    return f"{hash_local}@{domain}"

# UPDATE users SET email = CONCAT(
#   SUBSTR(SHA2(email, 256), 1, 10), '@', SUBSTR(email, LOCATE('@', email) + 1)
# );

Staging Ortamı Kurulumu

Bir staging ortamı oluşturmak, üretim doğruluğu ile altyapı maliyetleri arasında denge gerektiren bir görevdir. Mikro hizmet mimarisine sahip bir mobil proje için adım adım yaklaşıma bakalım.

Adım 1: Ortam Bileşimini Tanımlayın

Üretimin hangi bileşenlerinin staging'de bulunması gerektiğini belirleyin: API ağ geçidi, arka uç (mikro hizmetler), veritabanları, önbellek (Redis), kuyruklar (RabbitMQ/Kafka), dosya depolama (S3 uyumlu). Tam eşitlik için, aynı orkestratörü (Kubernetes) benzer sayıda kopyayla kullanın.

Adım 2: Staging'e Dağıtım için CI/CD Yapılandırın

Boru hattına, başarılı testlerden sonra yürütülen "Staging'e Dağıt" aşaması eklenir. Uygulama yapılandırması (URL uç noktaları, sandbox hizmetleri için API anahtarları) ortam değişkenleri veya CI sistemi sırları aracılığıyla iletilir.

Adım 3: Veri Anonimleştirme ve Senkronizasyon

Gerçekçi testler için, staging üretime benzer veriler içermeli ancak gizli bilgiler olmamalıdır. Periyodik olarak (günlük/haftalık) üretim verilerini kopyalayan ve PII'yi (kişisel verileri) anonimleştiren bir ETL süreci kurun.

• Database seeding — tüm iş senaryolarını kapsayan test verileriyle staging'i doldurmak için betikler
• Sır yönetimi — üretimle örtüşmeyen staging için ayrı anahtarlar (Vault, AWS Secrets Manager)
• Ağ politikaları — staging internete erişilebilir olmamalı veya katı bir IP beyaz listesine sahip olmalıdır

Staging için En İyi Uygulamalar

Bir staging ortamının etkili kullanımı, belirli kurallara uyulmasını gerektirir. Bu kuralları ihlal etmek staging'in değerini geçersiz kılar ve yanlış bir güvenlik hissi yaratır.

Üretimle Eşitlik

Staging, tüm parametrelerde üretime mümkün olduğunca yakın olmalıdır: işletim sistemi sürümleri, ağ gecikmesi, veri hacmi, hizmet örneği sayısı. Staging üretimden farklıysa, test sonuçları gerçek davranışı yansıtmayabilir.

Diğer Ortamlardan İzolasyon

Staging ayrı bir veritabanı, ayrı bir önbellek ve ayrı kuyruklar kullanır. Ortamları karıştırmak öngörülemeyen durumlara yol açar: bir geliştirici yanlışlıkla test verilerinin üzerine yazabilir veya regresyon test sonuçlarını etkileyebilir.

Otomatik Temizlik

Her test turundan sonra staging temiz bir duruma dönmelidir. Altyapıyı kod olarak yönetmek için Terraform veya Pulumi kullanın — bu, ortamı tek bir komutla yeniden oluşturmayı sağlar ve kimliğini garanti eder.

İzleme ve Uyarı

Staging'de üretimle aynı izleme yığını çalışmalıdır: günlükleme (ELK, Loki), metrikler (Prometheus, Datadog), izleme (Jaeger, Zipkin). Staging izlenmezse, orada bulunan sorunlar gözden kaçabilir.