Küçük ekipler için staging ile production: hangi parçaların eşleşmesi gerekir (DB, kimlik doğrulama, domainler) ve hangi parçaların sahtelenmesi uygun olur (ödeme, e-posta) — pratik bir kontrol listesiyle.

Secure ve SameSite davranışları farklıdır.\n\nAyrı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.\n\nBasit bir yaklaşım olarak birkaç bilinen hesap ekleyin:\n\n- Normal bir kullanıcı\n- Bir admin\n- Erişi olmayan bir kullanıcı (izin bloklarını doğrulamak için)\n- SSO-only bir kullanıcı (SSO destekliyorsanız)\n\n## Domainler, HTTPS ve uyumlu environment değişkenleri\n\nBirç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.\n\nEğ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.\n\nHTTPS 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.\n\nTarayıcıya bakan kurallara dikkat edin:\n\n- CORS allowlist'leri (yıldız değil, tam origin)\n- Çerez ayarları (domain, path, SameSite, Secure)\n- Yönlendirmeler (HTTP'den HTTPS'ye, www'den non-www'ye, trailing slash kuralları)\n- Oluşturulan linkleri ve auth davranışını etkileyen proxy/CDN header'ları, örneğin X-Forwarded-Proto\n\nBirç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:\n\n- BASE_URL (veya genel site URL'si)\n- Çerez domain ve oturum gizli anahtarları\n- CORS_ORIGINS\n- OAuth redirect ve callback URL'leri\n- Güvenilen proxy ayarları\n\n## Arka plan işleri, kuyruklar ve depolama: güvenilir olacak kadar yakın\n\nArka 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.\n\nProduction'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.\n\nZamanlanmış 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.\n\nDepolama ü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.\n\nGüveni artırmak için kasıtlı olarak hatalar oluşturun:\n\n- Yapay bir gecikme ekleyip işin timeout'a girdiğini ve retry yaptığını doğrulayın\n- Bir worker'ı öldürüp işin tekrar alındığını doğrulayın\n- Duplicate bir event (ör. webhook) gönderip çift işleme olmadığını kontrol edin\n- Boşluk ve Latin olmayan karakterler içeren dosya isimleri yükleyin\n\nİ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.\n\n## Neyi mock'lamalıyız: ödemeler, e-posta ve diğer riskli entegrasyonlar\n\nStaging 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.\n\nÖ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ı.\n\nE-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.\n\nPratik bir staging mock kurulumu genelde şunları içerir:\n\n- Sandbox ödemeler ve ortak webhook olaylarını tetikleme/yeniden oynatma yolu\n- E-postaların güvenli bir gelen kutusuna veya dahili bir outbox'a yönlendirilmesi\n- SMS ve push'un sadece test alıcılarına sınırlanması\n- Pahalı veya riskli üçüncü taraf API çağrıları için stub'lar\n- Test edenlerin neyin mocked olduğunu anlaması için UI'da ufak bir “mocked” bandı\n\nMock durumunu belirgin kılın. Aksi halde insanlar beklenen bir davranış için hata raporu açar.\n\n## Adım adım: aşırı büyütmeden staging kurmak\n\nUygulamanı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.\n\nSonra 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.\n\nKurulumu tekrarlanabilir kılın:\n\n- Bağımlılıkları must-match ve mocked olarak sınıflandırın\n- Staging deploy'unu tek bir tekrar edilebilir eylem yapın (script veya CI işi)\n- Deploy sırasında migration'ları çalıştırın\n- Migration başarısızsa veya sıra dışıysa deploy'u başarısız sayın\n- Temel bir rollback planı tutun (ör. “önceki versiyonu yeniden deploy et”)\n\nDeploy sonrası kısa bir smoke testi yapın:\n\n- Kayıt olun (veya seeded bir kullanıcı kullanın) ve girişin çalıştığını doğrulayın\n- Temel işlemi yapın (kayıt oluştur, sipariş ver, sayfa yayınla)\n- Sonuçların kullanıcıların beklediği yerde göründüğünü doğrulayın\n- Çıkış yapıp tekrar giriş yapın\n- Gerçek bir e-posta gönderilmediğini veya gerçek bir kartın ücretlendirilmediğini doğrulayın\n\nAlışkanlık haline getirin: temiz bir staging geçişi olmadan production'a sürüm göndermeyin.\n\n## Örnek: güvenli ödeme ve e-posta testi ile küçük bir SaaS sürümü\n\nBasit bir SaaS hayal edin: kullanıcılar kayıt olur, bir plan seçer, abonelik için ödeme yapar ve bir makbuz alır.\n\nÇ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.\n\nRiskli 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.\n\nBasit bir sürüm akışı:\n\n- Merge edip staging'e deploy edin\n- Migration'ları çalıştırın ve kayıt, giriş ve plan değişikliklerini smoke test edin\n- Ödeme başarısını ve hatasını simüle edin, ardından makbuzun güvenli şekilde yakalandığını doğrulayın\n- Aynı build'i production'a terfi ettirin\n\nStaging ile production kasıtlı olarak farklıysa (ör. staging'de ödemeler mocked ise), bunu kısa bir “bilinen farklar” notunda kaydedin.\n\n## “Staging'te çalıştı” hatalarının arkasındaki yaygın yanlışlar\n\nÇ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.\n\nSık tekrar eden hatalar:\n\n- Auth production'dan farklı bağlanmış. Farklı callback URL'leri, izin verilen domainler, grup eşlemeleri veya e-posta doğrulama kuralları.\n- Migrasyonlar tutarlı ele alınmamış. Birisi migration'ları lokal veya sadece production'da çalıştırıyor, staging tam zinciri çalıştırmıyor.\n- Gizli anahtarlar production'dan kopyalanmış. Hızlı hissettirse de staging sızıntısı daha ciddi sonuçlar doğurur.\n- Test verisi çok temiz. Süresi geçmiş abonelik yok, silinmiş kullanıcı yok, uzun isimler, eski kayıtlar veya timezone uç durumları yok.\n- 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.\n\nGerç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.\n\n## Her production deploy öncesi hızlı kontrol listesi\n\nKüçük ekipler aynı birkaç kontrolü her seferinde yaparak kazanır.\n\n- Konfigürasyon uyumu: auth callback'leri, çerez domaini, CORS ve base URL staging hostname'leriyle production beklentilerini karşılıyor mu\n- 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\n- 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ş\n- Görünürlük: staging deploy için logları açın, kontrollü bir hata tetikleyin ve bunu görebildiğinizi doğrulayın\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\n\n## Güvenlik ve veri güvenliği: staging'i bir yükümlülük haline getirmeyin\n\nStaging 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.\n\nVeriyle 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.\n\nEriş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.\n\nPratik bir temel seti:\n\n- Staging için ayrı gizli anahtarlar; periyodik olarak ve olay sonrası döndürülmüş\n- Sınırlı deploy ve veri erişimi (loglar ve veritabanları dahil)\n- Staging domaininde HTTPS ve temel güvenlik başlıkları\n- Log, yedek ve snapshotlar için açık saklama kuralları\n- Ülke/ Bölge kurallarınız varsa, ihtiyaç halinde staging'i production ile aynı ülkede çalıştırın\n\n## Sonraki adımlar: staging'i basit ve tutarlı tutun\n\nStaging 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.\n\nUygulanabilir 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.\n\nİ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.\n\nEğ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.\n\nSürümü onaylayabilecek kişi ile kontrol listesinin sahibi olanı belirleyin. Net sorumluluklar iyi niyetten her zaman daha etkilidir.Aynı ölçeğe sahip olmak değil, aynı sonucu üretmek hedeflenmelidir. Aynı kullanıcı eylemi her iki ortamda da aynı sebeple başarılı ya da başarısız oluyorsa, staging amacına hizmet ediyor demektir; makineler ve veri hacmi daha küçük olsa bile.
Para, veri veya erişimi etkileyebilecek değişikliklerde staging'e güvenilirlik kazandırın. Sık migrate yapıyorsanız, OAuth veya SSO kullanıyorsanız, önemli e-postalar gönderiyorsanız, ödeme işliyorsanız veya birden çok kişi değişiklik gönderiyorsa staging genellikle maliyetinden daha fazla zaman kazandırır.
Önce veritabanı migrasyonları ve şema — çünkü birçok “staging'te çalıştı” sürprizi buradan çıkar. Sonra kimlik doğrulama akışları ve domainler; callback'ler, çerezler ve HTTPS kuralları hostname değiştiğinde farklı davranma eğilimindedir.
Aynı migration aracını ve production'da kullandığınız koşulları kullanın. Production deploy sırasında migration çalıştırılıyorsa staging de öyle yapmalı; production onay adımı gerektiriyorsa staging de bunu taklit etmeli ki sıralama, kilitlenme ve rollback sorunlarını erken yakalayabilesiniz.
Hayır. 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ı maskeyle gizleyin ve erişimi sınırlayın; çünkü staging genellikle production kadar sıkı kontroller içermez.
Kullanıcı deneyimini aynı tutun, ancak ayrı kimlik bilgileri ve gizli anahtarlar kullanın. Staging için ayrı bir OAuth/SSO uygulaması oluşturun: kendi client ID, client secret ve izinli redirect URL'leri olsun; böylece staging hatası production hesaplarını etkilemez.
Production yapısına benzeyen bir staging domaini kullanın ve HTTPS'i aynı şekilde uygulayın. Bu, mutlak URL'ler, Secure ve SameSite gibi çerez bayrakları, yönlendirmeler ve proxy başlıklarıyla ilgili sorunları erken ortaya çıkarır.
Aynı tür kuyruk sistemini ve benzer retry/timeout ayarlarını kullanın ki gerçek ürün davranışını test edin. Staging'de arka plan işleri çok basitleştirilirse, retry'ler, gecikmeler ve çift olay işleme gibi production hatalarını kaçırırsınız.
Sandbox modlarını ve test anahtarlarını kullanın ki tam akışı gerçek yan etki olmadan çalıştırabilesiniz. E-posta ve SMS için mesajları güvenli bir yakalama kutusuna ya da dahili bir outbox'a yönlendirin; böylece gerçek müşterilere gönderim yapmadan içeriği ve tetiklemeleri doğrulayabilirsiniz.
Staging'i oyuncak bir ortam olarak değil, az kullanıcıya sahip gerçek bir sistem gibi ele alın. Ayrı gizli anahtarlar, en düşük ayrıcalık erişimi, log ve veri erişiminde sınırlamalar, HTTPS ve temel güvenlik başlıkları gibi uygulamalarla riskleri azaltın. Eğer Koder.ai kullanıyorsanız, staging'i ayrı bir ortamda tutun ve kötü bir deploy durumunda anlık görüntüler ve rollback ile hızlı geri dönüş sağlayın.