Küçük ekipler için Staging ve Production: hangi parçaları kopyalamalı, hangilerini taklit etmelisiniz?

Staging küçük ekipleri neden şaşırtmaya devam ediyor

Çoğu “staging'te çalıştı” hatası gizemli değildir. Staging genellikle gerçek ile sahteyi karıştırır: farklı bir veritabanı, farklı çevresel değişkenler, farklı bir domain ve bazen farklı bir oturum açma düzeni. UI aynı görünür, ama altında kurallar aynı olmayabilir.

Staging'in amacı, üretim benzeri hataları daha erken ortaya çıkarmaktır — düzeltmesi daha ucuz ve daha az stresli olduğunda. Bu genellikle gerçek koşullar altında davranışı kontrol eden parçaları eşleştirmek anlamına gelir: veritabanı şema değişiklikleri, kimlik doğrulama akışları, HTTPS ve domainler, arka plan işler ve kodun nasıl çalışacağını belirleyen environment değişkenleri.

Kaçınılmaz bir ödünleşme vardır: staging ne kadar “gerçek” olursa maliyeti o kadar artar ve riskleri de (yanlışlıkla bir karta ücret çekmek, gerçek kullanıcılara e-posta göndermek, veri sızıntısı). Küçük ekipler için staging, ikinci bir production haline gelmeden güvenilir olmalıdır.

İşinize yarayacak bir zihinsel model:

• Sonuçları değiştirenleri kopyalayın (migrasyonlar, kimlik doğrulama, domainler, kritik environment değişkenleri)
• İnsanlara veya bütçenize zarar verebilecekleri sahneleyin (ödemeler, e-posta, SMS, üçüncü taraf yan etkileri)

Staging ve production basitçe ne demek

Production gerçek sistemdir: gerçek kullanıcılar, gerçek para, gerçek veri. Bozulduğunda insanlar hemen fark eder. Güvenlik ve uyumluluk beklentileri yüksektir çünkü müşteri bilgilerini yönetiyorsunuz.

Staging ise değişiklikleri yayın öncesi test ettiğiniz yerdir. Uygulamanın bakış açısından production gibi hissetmeli, ama daha küçük bir etki alanına sahip olmalıdır. Amaç, bir migrasyonun başarısız olması, bir auth callback'in yanlış domaine işaret etmesi ya da arka plan işinin gerçek çalıştırmada farklı davranması gibi sürprizleri önceden yakalamaktır.

Küçük ekipler genellikle şu modellerden birine karar verir:

• Herkesin deploy ettiği tek bir paylaşılan staging uygulaması
• Pull request'ler için branch başına önizleme ortamları
• Yerel test + dikkatli, geri alınabilir production sürümleri

Uygulamanız çok küçük, değişiklikler nadir ve rollback anındaysa staging'i atlayabilirsiniz. Ancak ödeme alıyorsanız, önemli e-postalar gönderiyorsanız, sık migrasyon yapıyorsanız veya birden çok kişi değişiklik merge ediyorsa staging'i atlamayın.

Uyumluluk: davranışı eşleştirin, her şeyi değil

Parity (uyumluluk) staging'in production ile aynı trafik veya aynı harcama olması gerektiği anlamına gelmez. Aynı eylemler aynı sonuçlara yol açmalıdır demektir.

Bir kullanıcı kayıt oluyorsa, şifre sıfırlıyorsa, dosya yüklüyorsa veya bir arka plan işini tetikliyorsa, staging bu mantığı production'da olduğu gibi izlemelidir. Production ölçeğinde altyapıya ihtiyacınız yok ancak aynı varsayımlara sahip olmanız gerekir.

Pratikte işe yarayan basit bir kural:

Bir fark kontrol akışını, veri yapısını veya güvenliği değiştirebiliyorsa production ile eşleşmelidir.

Fark daha çok maliyet veya riski etkiliyorsa, bunu simüle edin.

Genelde şöyle ayrışır:

• Eşleştirilmeli: veritabanı migrasyonları ve şeması, kimlik doğrulama akışları (OAuth/SSO kuralları, oturumlar), domain/HTTPS davranışı, kritik environment değişkenleri ve feature flag'ler
• Simüle edilebilir: ödemeler, e-posta/SMS, push bildirimleri, üçüncü taraf analizler

İstisna yaptığınızda bunu bir yerde yazın. Kısa bir “staging notları” dokümanı yeterlidir: ne farklı, neden farklı ve gerçek şeyi nasıl güvenli test edersiniz. Bu küçük alışkanlık birçok gereksiz tartışmayı önler.

Veritabanı: migrasyonlar ve şema production ile aynı olmalı

Staging sürprizleri yakalamak için tasarlandıysa, sürprizlerin çoğu veritabanında saklıdır. Kural basit: staging şeması production ile aynı olmalı, veriler daha az olsa bile.

Aynı migration aracını ve aynı süreci kullanın. Production deploy sırasında migration çalışıyorsa staging de aynı şekilde çalıştırmalı. Production onay adımı gerekiyorsa staging de bunu kopyalamalı. Buradaki farklılıklar, kodun staging'de çalışmasının ama production'da başarısız olmasının klasik nedenidir.

Staging verisini daha küçük tutun, ama yapı aynı olsun: index'ler, constraint'ler, varsayılan değerler ve extension'lar. Eksik bir index staging'i hızlı hissettirebilirken production yavaşlar. Eksik bir constraint gerçek hataları müşterilere kadar gizleyebilir.

Yıkıcı değişiklikler ekstra dikkat ister. Yeniden adlandırma, drop ve backfill işlemleri küçük ekipleri yakalar. Staging'de tam diziyi test edin: migrate up, uygulamayı çalıştırın ve rollback destekliyorsanız onu da deneyin. Backfill'ler için, üretim ölçeğinde olmasa bile zaman aşımı veya kilit sorunlarını ortaya çıkaracak kadar satırla test edin.

Güvenli bir sıfırlama planlayın. Staging veritabanları karışır; baştan oluşturmak ve tüm migration'ları baştan çalıştırmak kolay olmalı.

Bir staging deploy'una güvenmeden önce doğrulayın:

• Migration'lar beklenen sırayla çalıştı mı
• Tablolar, sütunlar ve tipler production ile aynı mı
• Index'ler ve yabancı anahtarlar migration sonrası mevcut mu
• Yeni constraint'ler gerçekçi verileri reddetmiyor mu
• Backfill'ler makul bir sürede bitiyor mu

Kimlik doğrulama ve kullanıcı erişimi: aynı akışlar, ayrı kimlik bilgileri

Staging, production ile aynı giriş akışını kullanmıyorsa sizi yanıltır. Aynı yönlendirmeler, callback yolları, parola kuralları ve ikinci faktör (SSO/OAuth/magic link/2FA) gibi planladığınız deneyimi koruyun.

Aynı zamanda staging her yerde ayrı kimlik bilgileri kullanmalı. Staging için ayrı OAuth uygulamaları, client ID ve secret oluşturun; aynı kimlik sağlayıcıyı kullansanız bile. Bu production hesaplarını korur ve gizli anahtarları güvenle döndürmenize izin verir.

En çok hata çıkaran kısımları test edin: cookie'ler, oturumlar, yönlendirmeler ve callback URL'leri. Eğer production HTTPS kullanıyorsa staging de kullanmalı. Localhost'ta Secure ve SameSite davranışları farklıdır.

Ayrıca izinleri test edin. Staging sıkça “herkes admin” haline gelir ve production gerçek roller uygulandığında başarısız olur. Hangi rollerin olduğunu belirleyin ve en azından bir non-admin yolunu test edin.

Basit bir yaklaşım olarak birkaç bilinen hesap ekleyin:

• Normal bir kullanıcı
• Bir admin
• Erişi olmayan bir kullanıcı (izin bloklarını doğrulamak için)
• SSO-only bir kullanıcı (SSO destekliyorsanız)

Domainler, HTTPS ve uyumlu environment değişkenleri

Birçok “staging'te çalıştı” hatası URL'ler ve header'lardan kaynaklanır, iş mantığından değil. Staging URL'lerinin production'a benzemesini sağlayın, net bir önek veya alt domain ile.

Eğer production app.yourdomain.com ise staging staging.app.yourdomain.com (veya app-staging.yourdomain.com) olabilir. Bu, mutlak linkler, callback URL'leri ve yönlendirmelerle ilgili sorunları erken yakalar.

HTTPS davranışı da aynı olmalı. Production HTTPS zorunlu ise staging de aynı şekilde zorlamalı ve aynı yönlendirme kurallarını uygulamalı. Aksi halde Secure çerezleri sadece HTTPS üzerinden gönderildiği için staging'de çalışıyor gibi görünürken production'da başarısız olabilir.

Tarayıcıya bakan kurallara dikkat edin:

• CORS allowlist'leri (yıldız değil, tam origin)
• Çerez ayarları (domain, path, SameSite, Secure)
• Yönlendirmeler (HTTP'den HTTPS'ye, www'den non-www'ye, trailing slash kuralları)
• Oluşturulan linkleri ve auth davranışını etkileyen proxy/CDN header'ları, örneğin X-Forwarded-Proto

Birçok bunlardan environment değişkenlerinde saklanır. Bunları kod gibi gözden geçirin ve ortamlar arasında “şekil” (aynı anahtarlar, farklı değerler) tutun. Sık kontrol edilmesi gerekenler:

• BASE_URL (veya genel site URL'si)
• Çerez domain ve oturum gizli anahtarları
• CORS_ORIGINS
• OAuth redirect ve callback URL'leri
• Güvenilen proxy ayarları

Arka plan işleri, kuyruklar ve depolama: güvenilir olacak kadar yakın

Arka plan işleri staging'in sessizce bozulduğu yerdir. Web uygulaması iyi görünür, ama bir iş retry yapınca, kuyruk dolunca veya dosya yüklemesi izin kurallarıyla karşılaşınca sorunlar ortaya çıkar.

Production'da kullandığınız iş modelini staging'de de kullanın: aynı tür kuyruk, aynı worker kurulumu stili ve aynı retry/timeout kuralları. Production beş kez retry edip iki dakikalık timeout kullanıyorsa, staging tek sefer çalıştırıp timeout koymamalı. Bu farklı bir ürün test etmek olur.

Zamanlanmış işler ekstra özen ister. Zaman dilimi varsayımları ince hatalar yaratır: günlük raporların yanlış saatte oluşması, denemelerin erken bitmesi veya temizleyicilerin yeni dosyaları silmesi. Production ile aynı timezone ayarını kullanın veya farkı açıkça belgeleyin.

Depolama üretimde nasıl başarısız oluyorsa staging de benzer şekilde başarısız olacak kadar gerçek olmalı. Production nesne depolama kullanıyorsa, staging'in local klasöre yazmasına izin vermeyin. Aksi halde URL'ler, erişim kontrolleri ve boyut limitleri farklı davranır.

Güveni artırmak için kasıtlı olarak hatalar oluşturun:

• Yapay bir gecikme ekleyip işin timeout'a girdiğini ve retry yaptığını doğrulayın
• Bir worker'ı öldürüp işin tekrar alındığını doğrulayın
• Duplicate bir event (ör. webhook) gönderip çift işleme olmadığını kontrol edin
• Boşluk ve Latin olmayan karakterler içeren dosya isimleri yükleyin

İdempotentlik para, mesajlar veya webhook'lar söz konusu olduğunda en çok önem taşır. Staging'de bile işlerin yeniden çalışması çift ücret, çift e-posta veya tekrar eden durum değişiklikleri yaratmamalıdır.

Neyi mock'lamalıyız: ödemeler, e-posta ve diğer riskli entegrasyonlar

Staging production gibi hissettirmeli, ama gerçek kartları ücretlendirmemeli, gerçek kullanıcıları spamlememeli veya sürpriz API faturaları biriktirmemeli. Amaç gerçekçi davranış; sonuçlar güvenli.

Ödemeler genelde ilk mocklananlardır. Sağlayıcının sandbox modunu ve test anahtarlarını kullanın, sonra zor tekrar üretilebilen durumları simüle edin: başarısız ücretler, itirazlar, gecikmiş webhook olayları.

E-posta ve bildirimleri gerçek göndermek yerine her şeyi yakalama posta kutusuna ya da tek bir güvenli gelen kutusuna yönlendirin. SMS ve push için yalnızca test alıcıları kullanın ya da staging'e özel bir göndericiyle mesajları loglayıp düşürün; yine de içeriği doğrulayabilin.

Pratik bir staging mock kurulumu genelde şunları içerir:

• Sandbox ödemeler ve ortak webhook olaylarını tetikleme/yeniden oynatma yolu
• E-postaların güvenli bir gelen kutusuna veya dahili bir outbox'a yönlendirilmesi
• SMS ve push'un sadece test alıcılarına sınırlanması
• Pahalı veya riskli üçüncü taraf API çağrıları için stub'lar
• Test edenlerin neyin mocked olduğunu anlaması için UI'da ufak bir “mocked” bandı

Mock durumunu belirgin kılın. Aksi halde insanlar beklenen bir davranış için hata raporu açar.

Adım adım: aşırı büyütmeden staging kurmak

Uygulamanızın production'da dokunduğu her bağımlılığı listeleyerek başlayın: veritabanı, kimlik sağlayıcı, depolama, e-posta, ödemeler, analiz, webhook'lar, arka plan işler.

Sonra yan yana iki environment değişkeni seti oluşturun: staging ve production. Anahtarlar aynı olsun ki kod her yerde dallanmasın. Sadece değerler değişir: farklı veritabanı, farklı API anahtarları, farklı domain.

Kurulumu tekrarlanabilir kılın:

• Bağımlılıkları must-match ve mocked olarak sınıflandırın
• Staging deploy'unu tek bir tekrar edilebilir eylem yapın (script veya CI işi)
• Deploy sırasında migration'ları çalıştırın
• Migration başarısızsa veya sıra dışıysa deploy'u başarısız sayın
• Temel bir rollback planı tutun (ör. “önceki versiyonu yeniden deploy et”)

Deploy sonrası kısa bir smoke testi yapın:

• Kayıt olun (veya seeded bir kullanıcı kullanın) ve girişin çalıştığını doğrulayın
• Temel işlemi yapın (kayıt oluştur, sipariş ver, sayfa yayınla)
• Sonuçların kullanıcıların beklediği yerde göründüğünü doğrulayın
• Çıkış yapıp tekrar giriş yapın
• Gerçek bir e-posta gönderilmediğini veya gerçek bir kartın ücretlendirilmediğini doğrulayın

Alışkanlık haline getirin: temiz bir staging geçişi olmadan production'a sürüm göndermeyin.

Örnek: güvenli ödeme ve e-posta testi ile küçük bir SaaS sürümü

Basit bir SaaS hayal edin: kullanıcılar kayıt olur, bir plan seçer, abonelik için ödeme yapar ve bir makbuz alır.

Çekirdek davranışı etkileyenleri kopyalayın. Staging veritabanı production ile aynı migration'ları çalıştırır, böylece tablolar, index'ler ve constraint'ler eşleşir. Giriş aynı yönlendirmeleri ve callback yollarını izler, aynı kimlik sağlayıcı kurallarını kullanır ama ayrı client ID ve secret'lar olur. Domain ve HTTPS ayarları (çerez ayarları, yönlendirme kuralları) aynı şekle sahip olur; sadece hostname farklıdır.

Riskli entegrasyonları sahteleyin. Ödemeler test modunda veya success/fail döndürebilen bir stub üzerinde çalışsın. E-postalar güvenli bir gelen kutusuna ya da dahili bir outbox'a gitsin ki gerçek makbuzlar gitmesin ama içerik doğrulansın. Webhook olayları canlı sağlayıcıyı beklemek yerine kaydedilmiş örneklerden yeniden oynatılsın.

Basit bir sürüm akışı:

• Merge edip staging'e deploy edin
• Migration'ları çalıştırın ve kayıt, giriş ve plan değişikliklerini smoke test edin
• Ödeme başarısını ve hatasını simüle edin, ardından makbuzun güvenli şekilde yakalandığını doğrulayın
• Aynı build'i production'a terfi ettirin

Staging ile production kasıtlı olarak farklıysa (ör. staging'de ödemeler mocked ise), bunu kısa bir “bilinen farklar” notunda kaydedin.

“Staging'te çalıştı” hatalarının arkasındaki yaygın yanlışlar

Çoğu staging sürprizi, gerçek kimlik kuralları, gerçek zamanlama veya karışık veriler altında ortaya çıkan küçük farklılıklardan kaynaklanır. Her detayı eşlemek zorunda değilsiniz; önemli davranışların eşleşmesi hedef olsun.

Sık tekrar eden hatalar:

• Auth production'dan farklı bağlanmış. Farklı callback URL'leri, izin verilen domainler, grup eşlemeleri veya e-posta doğrulama kuralları.
• Migrasyonlar tutarlı ele alınmamış. Birisi migration'ları lokal veya sadece production'da çalıştırıyor, staging tam zinciri çalıştırmıyor.
• Gizli anahtarlar production'dan kopyalanmış. Hızlı hissettirse de staging sızıntısı daha ciddi sonuçlar doğurur.
• Test verisi çok temiz. Süresi geçmiş abonelik yok, silinmiş kullanıcı yok, uzun isimler, eski kayıtlar veya timezone uç durumları yok.
• Asenkron davranış göz ardı edilmiş. Webhook'lar, retry'ler ve kuyruk gecikmeleri sonucu değiştirir. 20 saniye sonra gelen bir webhook ile anında gelen bir webhook farklı problemlere yol açar.

Gerçekçi bir örnek: staging'de “plan yükselt” test ediyorsunuz, ama staging e-posta doğrulamasını zorunlu kılmıyor. Akış geçiyor. Production'da doğrulanmamış kullanıcılar yükseltme yapamaz ve destek hattı dolup taşıyor.

Her production deploy öncesi hızlı kontrol listesi

Küçük ekipler aynı birkaç kontrolü her seferinde yaparak kazanır.

• Konfigürasyon uyumu: auth callback'leri, çerez domaini, CORS ve base URL staging hostname'leriyle production beklentilerini karşılıyor mu
• Veri hazırlığı: production'da çalışacak tam migration'ları çalıştırın, şemanın doğru olduğunu doğrulayın ve temel seed kullanıcıların mevcut olduğundan emin olun
• Güvenli entegrasyonlar: ödemeler için sandbox anahtarları, e-posta güvenli gelen kutusuna yönlendirilmiş ve en az bir webhook olayı baştan sona test edilmiş
• Görünürlük: staging deploy için logları açın, kontrollü bir hata tetikleyin ve bunu görebildiğinizi doğrulayın
• Bir tam kullanıcı yolculuğu: kayıt ol -> e-posta doğrula -> workspace oluştur -> plan yükselt (sandbox) -> çıkış yap -> tekrar giriş yap

Güvenlik ve veri güvenliği: staging'i bir yükümlülük haline getirmeyin

Staging genellikle production'dan daha zayıf güvenliğe sahiptir, ama yine de gerçek kod, gerçek gizli anahtarlar ve bazen gerçek veriler barındırabilir. Staging'i az kullanıcıya sahip gerçek bir sistem gibi muamele edin, oyuncak ortam olarak değil.

Veriyle başlayın. En güvenli varsayılan staging'de gerçek müşteri verisi bulundurmamaktır. Bir hatayı yeniden üretmek için production verisini kopyalamanız gerekiyorsa, hassas alanları (e-posta, isim, adres, ödeme detayları) maskeyle gizleyin ve kopyayı küçük tutun.

Erişimi ayrı ve minimal tutun. Staging'in kendi hesapları, API anahtarları ve azami izinlerle çalışması gerekir. Bir staging anahtarı sızarsa production'a erişmemeli.

Pratik bir temel seti:

• Staging için ayrı gizli anahtarlar; periyodik olarak ve olay sonrası döndürülmüş
• Sınırlı deploy ve veri erişimi (loglar ve veritabanları dahil)
• Staging domaininde HTTPS ve temel güvenlik başlıkları
• Log, yedek ve snapshotlar için açık saklama kuralları
• Ülke/ Bölge kurallarınız varsa, ihtiyaç halinde staging'i production ile aynı ülkede çalıştırın

Sonraki adımlar: staging'i basit ve tutarlı tutun

Staging ancak ekip haftadan haftaya çalıştırabildiği sürece yardımcı olur. Mükemmel ayna olmayın; sürdürülebilir bir rutin hedefleyin.

Uygulanabilir hafif bir standart yazın: ne eşleşmeli, ne mock'lanmalı ve “yayına hazır” ne demek. Kısa tutun ki insanlar okusun.

İnsanların unuttuğu işleri otomatikleştirin. Merge olduğunda otomatik staging deploy, deploy sırasında migration'ları çalıştırma ve temel smoke testleri süreklileştirin.

Eğer Koder.ai (koder.ai) ile inşa ediyorsanız, staging'i ayrı bir ortam olarak tutun: ayrı gizli anahtarlar ve domain ayarları kullanın; anlık görüntüler ve rollback'i normal sürüm rutinine dahil edin ki kötü bir deploy hızlıca geri alınabilsin.

Sürümü onaylayabilecek kişi ile kontrol listesinin sahibi olanı belirleyin. Net sorumluluklar iyi niyetten her zaman daha etkilidir.