Çoklu Ortam Yönetimi: Dev, Test, Staging ve Prod İçin Bakım Modeli

Her ortamın bir “rolü” vardır. Rol net değilse, ortamlar birbirine karışır ve risk büyür. Bu nedenle çoklu ortam bakım modeli, web ve yazılım projelerinde production riskini azaltan temel bakım standardı olarak ele alınmalıdır.

Dev: deney ve hızlı iterasyon alanı

• •Hızlı prototip, deneme, branch bazlı geliştirme
• •Kırılabilir; veri gerçekçi olmak zorunda değildir
• •Amaç: hızlı öğrenme, hızlı değişiklik

Test: doğrulama ve regresyon alanı

• •Otomatik testler (unit/integration/e2e)
• •Manual test senaryoları (kritik akışlar)
• •Amaç: “bu değişiklik doğru mu?” sorusunu cevaplamak

Staging: prod’a en yakın prova alanı

• •Prod’a yakın konfigürasyon (env parity)
• •Gerçeğe yakın veri/senaryo (gizlilik kurallarıyla)
• •Amaç: “prod’da nasıl davranır?” sorusunu cevaplamak

Prod: kontrollü yayın ve izleme alanı

• •Sadece kurallı change türleri
• •İzleme/alarmlar aktif
• •Amaç: stabilite ve iş sürekliliği

Soru : Dev, test, staging ve prod ortamları arasındaki fark nedir?

Cevap: Dev deneme ve geliştirme içindir; test doğrulama/regresyon içindir; staging prod’a en yakın prova ortamıdır; prod ise sadece kontrollü değişikliklerin yayımlandığı canlı ortamdır. Bu ayrım, yanlış ortamda yanlış işlem riskini azaltır.

Yanlış ortamda yapılan işlem, en çok iki tür krize yol açar: (1) yanlış test sonucu (yanıltıcı başarı), (2) prod incident/rollback. Bu yüzden “yapılacaklar/kaçınılacaklar” tablosu pratikte en hızlı kazanımdır.

Ortam bazlı yapılacaklar/kaçınılacaklar (özet)

Aşağıdaki tablo, ekibin “hangi ortamda ne yapılır?” sorusunu tek sayfada yanıtlar.

Soru : Hangi değişiklik hangi ortamda test edilmeli?

Cevap: Deneysel değişiklikler dev’de, doğrulama test’te, prod’a yakın senaryolar staging’de test edilmelidir. Prod’da ise sadece onaylı change türleri yayınlanır ve post-release kontrolleri yapılır. Özellikle staging bakım akışı net değilse, staging’den prod’a geçiş kişisel yoruma açık hale gelir.

Çoklu ortamın işe yaraması için “parite” gerekir. En sık yaşanan problem: staging ile prod arasında konfigürasyon ve versiyon drift’inin oluşması. Sonuç: “staging’de çalışıyordu” cümlesi. Özellikle modern web projelerinde staging test akışı kurulmadığında, versiyon güncelleme ve refactoring işleri prod’a gereğinden fazla risk taşır.

Parite (env parity) için 5 temel prensip

1. Versiyon uyumu: app/runtime/dependency sürümleri yakın olmalı
2. Konfig uyumu: env değişkenleri ve feature flag’ler tutarlı olmalı
3. Dış servis uyumu: ödeme/PMS/OTA/CRM gibi servislerin staging karşılığı net olmalı
4. Cache/CDN davranışı: staging’de hiç cache yoksa prod sürpriz çıkarır
5. Gizlilik: prod verisini kopyalama yerine maskelenmiş/sentetik veri tercih edilmeli

Yeni sürüm veya bakım değişikliğinin canlıya çıkmadan önce doğrulanması için staging ortamında performans regresyon testi uygulanmalı; böylece hız düşüşleri ve Core Web Vitals sapmaları prod’a taşınmadan yakalanmalıdır.

Release öncesinde prod öncesi teknik SEO kontrolü ile canonical, robots, sitemap, yönlendirme ve indexleme farkları staging üzerinde doğrulanmalıdır.

Drift’i azaltan pratikler

• •IaC (Infrastructure as Code) ile ortam kurallarını kodlamak
• •Secrets yönetimi ve rotasyon standardı
• •“Config diff” kontrolleri (deploy öncesi)
• •Versiyon güncellemelerinde kademeli ilerleme

Key Statistics / Data Point (yumuşatılmış): Ortam sınırları ve kuralları net olan projelerde, bakım ve release süreçleri genelde daha öngörülebilir ve kontrollü ilerler; “testte yoktu” söylemleri azalır.

Otel ve B2B’de çoklu ortam mimarisi benzer görünse de kritik akışlar farklıdır. Özellikle otel projelerinde production değişiklik riski kampanya ve yüksek sezon dönemlerinde daha görünür hale gelir.

Otel: 4 ortamda kritik akışlar

• •Dev: kampanya bileşenleri, UI testleri
• •Test: rezervasyon funnel senaryoları (mobil + çok dilli), form testleri
• •Staging: PMS/OTA entegrasyon healthcheck, cache/CDN, sezon öncesi yük senaryoları
• •Prod: yalnız kontrollü release + izleme; sezonda change freeze yaklaşımı

B2B: 4 ortamda kritik akışlar

• •Dev: feature branch + API değişiklikleri
• •Test: integration tests, contract tests
• •Staging: prod’a yakın auth/permissions, ödeme senaryoları, dashboard veri doğrulama
• •Prod: planlı release pencereleri, post-release KPI kontrolü

Soru : Otel ve B2B projelerinde çoklu ortam mimarisi nasıl olmalı?

Cevap: Temel 4 ortam (dev/test/staging/prod) korunmalı; staging prod’a yakın kurgulanmalı ve kritik akışlar (otel: rezervasyon+PMS/OTA; B2B: API+portal+ödeme) staging’de uçtan uca doğrulanmalıdır. Prod’da ise yalnız kontrollü değişiklik yayınlanmalıdır. Bu doğrulamanın çıktıları ortam bazlı release raporlaması ile izlenirse, deploy kalitesi ve hata trendleri daha görünür olur.

Deliverables listesi

• •Ortam rolleri & yetki matrisi
• •Ortam bazlı yapılacaklar tablosu
• •Change flow + staging gate kuralları
• •Parite/drift checklist’i
• •Post-release kontrol listesi

Çoklu ortam çoğu yerde “var” ama kuralları yazılı değildir; bu da disiplin eksikliğine yol açar. Bu rehber, ortam rollerini netleştirip “hangi işlem hangi ortamda” tablosu ve parite prensipleriyle uygulanabilir bir model verir. Böylece ekip, hız ve risk arasında sağlıklı denge kurar. Bu yapıyı operasyonel standarda dönüştürmek için Bakım ve Destek hizmetiyle environment parity sürecinizi netleştirin; süreç ve kapsam detayları için Bakım ve Destek hakkında sık sorulan sorular sayfasına da göz atabilirsiniz.