Ayakta kalan no-code uygulamalar için dev, staging, prod ortamları

Neden ortam ayrımı önemli (ve nerede bozuluyor)\n\nİnsanlar dev, staging ve prod ortamlarından bahsederken tek bir vaatten söz ederler: gerçek müşterileri, gerçek veriyi veya gerçek parayı riske atmadan şeyleri güvenle deneyebilirsiniz.\n\nBu vaat, dev ile prod arasında önemli herhangi bir şey paylaşıldığı anda bozulur; özellikle veritabanı veya API anahtarları paylaşılıyorsa. “Küçük bir test” gerçek bir olaya dönüşür çünkü uygulama alıştırmayla gerçeği ayıramaz.\n\nBasitçe söylemek gerekirse:\n\n- Dev hızlıca inşa edip değiştirdiğiniz yerdir. Dağınık olmasına izin verilir.\n- Staging üretime benzeyen bir prova alanıdır ve sürümleri uçtan uca doğrulamak için kullanılır.\n- Prod gerçek kullanıcıların güvendiği yerdir. Dikkatle değişmelidir.\n\nAyrım, her değişikliği yüksek riskli olarak görmeyi bıraktığınız için daha hızlı hareket etmenizi sağlar.\n\nGerçek dünya örneği şöyle olur: biri yeni bir ödeme akışını test eder ama uygulama üretim Stripe anahtarlarını kullanıyordur. “Test” gerçek ücretler oluşturur, gerçek makbuzlar tetikler ve destek ekibi bütün öğleden sonra iade işlemleriyle uğraşır. Ya da biri dev'de bir veri temizleme betiği çalıştırır ama hedef paylaşılan üretim veritabanıdır ve müşteri kayıtları silinir. Bir diğer yaygın örnek: bir e-posta özelliği canlı sağlayıcıyla test edilir ve binlerce gerçek kullanıcıya “Hoş geldiniz!” mesajı gönderilir.\n\nÇoğu bozulma aynı üç kaynaktan gelir: paylaşılan veritabanları (test gerçek kayıtları değiştirir), paylaşılan kimlik bilgileri (test gerçek hizmetleri çağırır) ve paylaşılan entegrasyonlar (webhook'lar, e-postalar, SMS ve ödemeler gerçek olarak tetiklenir).\n\nAppMaster gibi platformlar hızlı inşa etmeyi kolaylaştırır, ama güvenlik hâlâ veriyi, gizli bilgileri ve entegrasyonları baştan ayırmanıza bağlıdır.\n\n## Uyabileceğiniz basit bir ortam modeli seçin\n\nÇoğu ekip için en iyi olan üç ortamdır: dev, staging ve prod. Bu, işi düzenli tutar ve kurulumun ayrı bir yan proje haline gelmesini engeller.\n\nAynı uygulama için üç ayrı “dünya” gibi davranın. Her birinin kendi veritabanı, kendi kimlik bilgileri ve kendi entegrasyon ayarları olmalı. Böylece bir test kayıt oluşturma, hatalı bir otomasyon veya yanlış yapılandırılmış bir API çağrısı prod verilerine dokunamaz.\n\nÇok erken prototipler için iki ortam kabul edilebilir: “dev” ve “prod”. Hız ve maliyet kazanırsınız ama güvenli bir prova alanından vazgeçersiniz. Uygulamayı takım dışından insanlar kullanıyorsa risk hızla artar.\n\nİnsanlar, uyumluluk veya entegrasyonlar ciddileştiğinde üçten fazla ortama ihtiyacınız olabilir. Yaygın eklemeler arasında UAT (kullanıcı kabul testi), entegrasyon testi için ayrılmış bir sandbox veya acil düzeltmeler için geçici bir hotfix ortamı bulunur. Daha fazla ekliyorsanız, isimleri sıkıcı ve öngörülebilir tutun: dev, staging, uat, prod. “staging2”, “final-final” veya yalnızca ekiplerin anlayacağı etiketlerden kaçının.\n\nHer ortam maliyet ve zaman artırır, ama bir üretim olaydaki maliyetten çok daha azdır. Ek barındırma, ekstra veritabanları ve gizli bilgiler ile entegrasyonların kurulumu için biraz zaman bekleyin. AppMaster gibi bir no-code platformunda, ortam ayarlarını değiştirirken uygulama mantığını tutarlı tutmanın faydası vardır.\n\n## Dev, staging ve prod’u mantıklı tutan beş kural\n\nBunlar “hızlı testleri” kesintiye dönüştürmekten alıkoyan ve sık yayınlarda bile işleri sakin tutan kurallardır.\n\n1) Ortamlar arasında asla veritabanı paylaşmayın. Dev ve staging üretim tablolarına işaret etmemelidir, hatta “yalnızca okunur” olanlar bile. Ayrı veritabanı örnekleri kullanın veya en azından katı izinlerle ayrı şemalar kullanın.\n\n2) Her yerde farklı gizli bilgiler kullanın. Veritabanı kullanıcıları, API anahtarları, webhook imzalama gizli anahtarları, OAuth istemci gizli anahtarları ve şifreleme anahtarları her ortam için benzersiz olmalıdır. Bir dev anahtarı ekran görüntüsünde veya sohbet mesajında sızarsa sadece dev riske atılmalıdır.\n\n3) Entegrasyonları iki sistem olarak ele alın: test ve canlı. Sandbox hesapları veya test modları kullanın. Bir sağlayıcı sunmuyorsa bir güvenlik anahtarı oluşturun (dev'de giden çağrıları devre dışı bırakın, sahte bir alıcıya gönderin veya çağrıları bir özellik bayrağının arkasına alın). Bu ödeme, mesajlaşma ve otomasyonlar için önemlidir.\n\n4) Üretim değişikliklerini kısıtlayın. Üretimde düzenleme haklarına sahip kişi sayısı az olmalı ve daha güçlü onay süreçleri olmalıdır. No-code araçlarda “küçük” UI düzenlemeleri bile mantığı etkileyebilir, bu yüzden prod ekstra özen gerektirir.\n\n5) Sadece tek yönlü terfiyi kullanın. Değişiklikler dev → staging → prod şeklinde ilerlemelidir. Prod'u doğrudan ani düzeltmelerle değiştirmekten kaçının; çünkü düzeltmeyi geri getirmeyi unutmak veya sonraki dağıtımın onu ezmesi kolaydır.\n\nÖrnek: AppMaster'da bir destek portalı inşa ediyorsunuz. Dev'de bir dev PostgreSQL veritabanına ve test Stripe hesabına bağlanırsınız. Staging'de şemanın temiz bir kopyasını ve sadece staging için API anahtarlarını kullanıp tam bir gerçekçi testi çalıştırırsınız. Staging onaylandıktan sonra prod'a production anahtarları ve production veritabanıyla dağıtım yaparsınız.\n\n## Veritabanları: ayırın, seedleyin ve güvenle geçiş yapın\n\nDev, staging ve prod aynı veritabanını paylaşıyorsa aslında ayrı ortamlara sahip değilsiniz demektir. Tek bir zararsız test gerçek veriyi üzerine yazabilir, e-postaları tetikleyebilir veya raporlamayı bozabilir. Veritabanı ve dosya depolamayı ortamın sahip olduğu kaynaklar olarak görün, paylaşılan araçlar olarak değil.\n\nVeriyi ayırmanın birkaç temiz yolu var. En iyi seçim, ekibinizin her seferinde gerçekten uygulayacağı seçimdir:\n\n- Ayrı veritabanı sunucuları (en iyi izolasyon): Prod kendi PostgreSQL örneğinde çalışır. Dev ve staging başka yerde çalışır.\n- Aynı sunucuda ayrı veritabanları: Aynı PostgreSQL host'ta app_dev, app_staging, app_prod.\n- Ayrı şemalar (sadece gerekliyse): Tek bir veritabanı içinde dev, staging, prod şemaları. Bu karıştırması en kolay olan yaklaşımdır, bu yüzden ek güvenlik önlemleri ekleyin.\n\nNe seçerseniz seçin, isimlerde ve bağlantı ayarlarında bariz olmasını sağlayın. Prod veritabanı adı ve host'unu staging ile karıştırmak zor olsun.\n\n### Seed verisi: test için yeterince gerçek, uyuyabilmeniz için yeterince güvenli\n\nStaging üretime benzemeli ama gerçek kişisel veriler olmadan. Yaygın yaklaşımlar, kontrolünüzde küçük bir seed veri seti, üretimin anonimleştirilmiş bir anlık görüntüsü veya gerçek biçimleri ve uç durumları taklit eden sentetik verilerdir.\n\nBir destek portalı için “İade talebi” ve “Giriş sorunu” gibi sentetik ticket'lar arama, filtreleme ve rollerin test edilmesi için yeterlidir, müşteri mesajlarını açığa çıkarmadan.\n\n### Güvenli göç: önce staging, sonra prod\n\nŞema değişiklikleri birçok olaya neden olur. Güvenli bir desen: \n\n- Değişiklikleri önce staging'e uygulayın ve hızlı bir smoke testi çalıştırın.\n- Prod'a dokunmadan önce bir yedek/geri yükleme noktası oluşturun.\n- Prod'da göçleri sessiz bir pencerede çalıştırın ve bir geri alma planınız olsun.\n- Tek adımda kıran değişikliklerden kaçının (ör. bir sütunu silmek). Aşamalandırın.\n\nAppMaster'da Data Designer değişiklikleri sonunda PostgreSQL'de veritabanı değişiklikleri olur, bu yüzden her yayın bir göç gibi ele alınmalıdır.\n\nNon-prod'dan prod'a yanlış yazmayı önlemek için: ortam başına farklı kimlik bilgileri kullanın, dev makinelerinin prod'a erişemeyeceği şekilde ağ erişimini sınırlandırın ve analiz için yalnızca okunur hesaplar kullanın.\n\nDosyalar ve ekleri unutmayın. Test yüklemeleri veritabanı satırları kadar kolayca gerçek kullanıcı kayıtlarına sızabileceğinden ortam başına ayrı bucket'lar veya açıkça ayrılmış klasörler tutun.\n\n## Kimlik bilgileri ve gizli bilgiler: uygulamanın ve sohbette olmamalılar\n\nGizli bilgiler, birinin kopyalaması size zarar verirlerse sorun olan her şeydir. Dev, staging ve prod ortamlarında yaygın adaylar veritabanı parolaları, OAuth istemci gizli anahtarları, Stripe anahtarları, e-posta veya SMS sağlayıcı anahtarları ve Telegram bot token'larıdır.\n\nGizli bilgileri elektriğe benzetin: ihtiyaç duyulan yerde erişilebilir, asla açığa çıkmamalıdır. Bu, no-code projenize sert kodlarla koymamak, biletlerde yapıştırmamak ve “geçici” paylaşımlarla chat'te dağıtmamak demektir.\n\nPratik bir kural: bir ortam, bir gizli seti. Ortam değişkenleri (veya platformunuzun gizli depo alanı) ve net bir adlandırma düzeni kullanın.\n\n- DEV_DB_PASSWORD, DEV_OAUTH_CLIENT_SECRET, DEV_STRIPE_SECRET_KEY\n- STAGING_DB_PASSWORD, STAGING_OAUTH_CLIENT_SECRET, STAGING_STRIPE_SECRET_KEY\n- PROD_DB_PASSWORD, PROD_OAUTH_CLIENT_SECRET, PROD_STRIPE_SECRET_KEY\n\nAppMaster'da bu değerleri her dağıtım hedefi için ortam-spesifik ayarlarda tutun. Uygulama mantığı yalnızca değişken adıyla referans vermeli, gerçek değeri asla içermemelidir.\n\nErişim depolama kadar önemlidir. Gizli bilgileri görebilen veya düzenleyebilen kişi sayısını mümkün olduğunca az tutun ve kim, ne zaman, neden değiştirdi kaydı tutun. Hafif bir değişiklik günlüğü bile belleğe güvenmekten iyidir.\n\nDöndürme (rotation) korkutucu olmak zorunda değil, ama normal olmalı. Bir ekip üyesi ayrıldığında, bir değer aşırı paylaşıldığında, şüpheli aktivite görüldüğünde ve üretim için düzenli periyotlarda anahtarları döndürün.\n\nDöndürme sonrası, o gizli bilgiye bağımlı akışları tekrar test edin: oturum açma (OAuth veya parola akışları), ödemeler (test-modu akışı), e-posta/SMS teslimatı (test adresine/numarasına) ve üçüncü taraf API'leri çağıran arka plan işler.\n\nSon olarak, kazara sızıntıları önleyin. Gizli bilgileri ekran görüntülerine, dökümanlara veya “hızlı örneklere” koymayın. Bir konfigürasyon göstermeniz gerekiyorsa yer tutucular kullanın (ör. PROD_STRIPE_SECRET_KEY=xxxx).\n\n## Entegrasyonlar: gerçek servisleri çağırmadan güvenle test edin\n\nEntegrasyonlar, dev, staging ve prod'un genellikle bozulduğu yerdir; çünkü yanlış bir anahtar gerçek ücretler, gerçek e-postalar veya gerçek veri değişiklikleri tetikleyebilir. Non-prod'da uygulamanız üretim gibi davranmalı, ama hasarı imkansız kılacak önlemlerle.\n\nÖdemeler için net bir kural: yalnızca üretim canlı modu kullanır. Dev ve staging'de test modu ve ayrı test ürünleri, fiyatlar ve webhook'lar kullanın. Bu, tam ödeme akışını gerçek para riski olmadan çalıştırmanızı sağlar.\n\nE-posta ve SMS için non-prod mesajların hata olduğunu varsayın taşın. Giden mesajları güvenli bir hedefe yönlendirin (tek bir dahili gelen kutusu veya kontrollü bir telefon numarası gibi) veya varsayılan olarak gönderimi devre dışı bırakın ve yalnızca belirli test kullanıcıları için açın. AppMaster modüllerini e-posta/SMS veya Telegram için kullanıyorsanız aynı kuralı uygulayın: non-prod gerçek müşterilere asla ulaşmamalıdır.\n\nWebhook'ların kendi ayrımı olmalı. Ortam başına farklı uç noktalar oluşturun ve imzaları her yerde doğrulayın, sadece üretimde değil. Bu, staging trafiğinin production işleyicilerine gitmesini engeller ve yanlış yönlendirmeleri erken yakalamanıza yardım eder.\n\nÜçüncü taraf API sandbox sunuyorsa onu kullanın. Sunmuyorsa katı rate limitler ve mümkünse yalnızca okuma izinleri ekleyin; non-prod çağrıları kolayca fark edilebilsin (ör. belirgin bir header veya etiket).\n\nÇoğu olayı yakalayan bir güvenlik kontrol listesi:\n\n- Dev, staging ve prod için ayrı entegrasyon hesapları/projeleri\n- Non-prod kimlik bilgileri üretim kaynaklarına erişemez\n- Zamanlanan işler non-prod'ta varsayılan olarak kapalı veya sadece sandbox servislerine karşı çalışır\n- Webhook URL'leri ve imza gizli anahtarları ortam başına benzersizdir\n- Test mesajları ve test ücretlendirmeleri açıkça etiketlenmiştir\n\nÖrnek: staging destek portalınız sahte ödemeler oluşturabilir ve bildirim gönderebilir, ama her mesaj takım gelen kutusuna gider ve gece işleri sadece staging verisi üzerinde çalışır.\n\n## Erişim kontrolü ve onaylar: kim nerede neyi değiştirebilir\n\nErişim kontrolü dev, staging ve prod için güvenlik korkuluğudur. No-code uygulamalarda birçok olay, biri prod'da bir şeyi iyi niyetle değiştirince olur.\n\nBirkaç rol ile başlayın ve bunları net tutun. Küçük bir ekip bile basit izinlerden fayda görür: görüntüleyebilen, test edebilen, dev/staging'de düzenleyebilen ve ortamları/gizli bilgileri dağıtabilen küçük bir grup.\n\nProd erişimini düşündüğünüzden daha küçük tutun. Bir kişi haftada prod'a ihtiyaç duymuyorsa kalıcı erişim vermeyin. Birine gerekli olduğunda (ör. canlı bir olayı araştırmak için), kısa süreli yükseltilmiş erişim verin ve iş bitince kaldırın.\n\nProd'a dokunmadan önce hafif bir onay adımı ekleyin, özellikle yayınlar ve veritabanı değişiklikleri için. Pratikte bu, bir kişinin yayını hazırlaması ve ikinci bir kişinin onaylaması olabilir. AppMaster kullanıyorsanız, “prod'a yayınla” ve “şema değişikliklerini uygula” eylemlerinin herhangi bir düzenleyenin yapabileceği işler değil, açık izin isteyen adımlar gibi davranmasını sağlayın.\n\nHızlıca üç soruya cevap verebilecek temel bir denetim izi tutun: kim neyi değiştirdi, ne zaman ve hangi ortamda.\n\nGerekmeden önce bir geri alma planı düz yazı ile hazırlayın. Hangi işlemlerin hızlıca geri alınabileceğini (önceki sürümü yeniden dağıtma, bir özellik bayrağını kapatma) ve hangilerinin geri alınamayacağını (veri silme, geri döndürülemez göçler) açıkça belirtin; ayrıca kimlerin geri almaya yetkili olduğunu ve kurtarmayı nasıl teyit edeceğinizi yazın.\n\n## Adım adım: bir no-code uygulama için dev, staging ve prod kurun\n\nÖncelikle hangi şeylerin ortamlarda asla paylaşılmaması gerektiğini yazın: veritabanı, gizli bilgiler (API anahtarları, token'lar) ve gerçek e-posta gönderebilen, kart çekebilen veya müşteriye mesaj atabilen entegrasyonlar. Sadece bir şeyi ayırabiliyorsanız, veritabanını ayırın.\n\nTekrar eden ve karmaşaya düşmeyen bir kurulum:\n\n1) Ortamları adlandırın ve sınırları belirleyin. Tutarlı isimler kullanın (Dev, Staging, Prod). Her birinin kendi veritabanı, kendi gizli bilgileri ve kendi entegrasyon hesapları veya test modları olduğunu kararlaştırın.\n\n2) Aynı mantığı koruyarak uygulamayı ayrı konfigürasyonlarla klonlayın. AppMaster gibi bir no-code platformunda aynı uygulamanın Dev ve Staging sürümlerini oluşturun. Mantığı aynı tutun, ama ortam ayarlarını ayrı tutun (veritabanı bağlantı dizeleri, API anahtarları, webhook URL'leri).\n\n3) Veritabanlarını oluşturun ve seedleyin, sonra sınırı doğrulayın. Üç veritabanı (ya da zorunlu kalırsanız üç izole şema) oluşturun. Dev ve Staging'i gerçekçi ama sahte verilerle seedleyin. Hızlı bir sınır kontrolü yapın: Staging'de bir kayıt oluşturun ve Prod'da görünmediğini doğrulayın; tersini de deneyin.\n\n4) Entegrasyonları güvenli moda alın ve webhook'ları doğrulayın. Ödemeler test modunda olmalı, e-posta sandbox gelen kutusuna gitmeli, mesajlaşma test kanalına yönlendirilmeli. Tam akışı tetikleyin (kullanıcı kaydı, şifre sıfırlama, ödeme denemesi) ve webhook'ların sadece eşleşen ortamda geldiğini doğrulayın.\n\n5) Staging kontrol listesini çalıştırın, sonra aynı değişikliği terfi ettirin. Staging'de ana yolculukları, izinleri ve hata yollarını test edin. Temizse aynı değişiklikleri Prod'a uygulayın (Prod'da yalnızca hızlı düzeltmeler yapmaktan kaçının).\n\nYayın sonrası kısa bir izleme penceresi bırakın: logları, başarısız istekleri ve entegrasyon panellerini izleyin. Trafik normale dönene kadar geri alma seçeneğini hazır tutun (önceki build, önceki konfigürasyon veya bir özellik bayrağı).\n\n## Örnek senaryo: destek portalını gerçek kullanıcıları riske atmadan yayınlamak\n\nKüçük bir operasyon ekibi dahili bir destek portalı inşa ediyor: temsilciler oturum açıyor, müşterileri arıyor, Stripe'da ek özellikler için ücret alıyor ve bir ticket durumu değiştiğinde e-posta güncellemeleri gönderiyor. Testlerin gerçek para veya gerçek gelen kutulara dokunmaması için üç ortam üzerinden yönetiyorlar.\n\nDev'de her şey varsayılan olarak sahte. Veritabanı ayrı ve seed verilerle dolu (ör. örnek müşteriler, örnek ticket'lar, eksik e-posta gibi sorunlu durumlar). Kimlik doğrulama test kullanıcı dizinine veya küçük bir test hesap setine yöneltilir. Stripe test modunda ve test kartları kullanılır, e-posta sandbox posta kutusuna gider (veya devre dışı bırakılıp loglanır).\n\nStaging'in hedefi riski olmadan neredeyse gerçeğe yakın olmaktır. Veritabanı ayrı ama üretimden güvenli şekilde yenilenmiş (ör. anonimleştirilmiş isimler ve e-postalar). Kimlik doğrulama üretime benzer ayarlara sahiptir ama erişim sınırlıdır. Stripe test modunda kalır, ama ekip gerçekçi ödeme ve iade akışlarını çalıştırır. E-posta sadece onaylı dahili adreslere izinlidir.\n\nProd'da portal sıkı kontrol altındadır. Sadece onaylı yöneticiler entegrasyonları değiştirebilir veya deploy yapabilir. Gerçek Stripe anahtarları ve gerçek e-posta gönderimi etkin, ve denetim logları açıktır.\n\nYeni bir özellik: tek tıkla iade (refund) iş akışı. Bir geliştirici bunu AppMaster'da Business Process Editor ile oluşturur, dev'de test kartlarıyla test eder ve UI metinlerini kontrol eder.\n\nStaging'de güvenli bir hata görünür: iade mantığı aynı statü değişikliğinde iki adım tetiklendiği için “ticket kapandı” e-postasını iki kez gönderir. Prod'da bu müşteri spam'ine ve ajanların karışmasına neden olacaktı. Staging'de sadece dahili gelen kutulara gittiği için ekip koşulu düzeltiyor ve tekrar test ediyor.\n\nBirkaç temel şeyi belgeleyip kimsenin sonra tahmin etmesine gerek kalmamasını sağlıyorlar: ortam isimleri ve sahipleri, anahtarların nerede saklandığı ve kimlerin döndürebildiği, hangi veritabanlarının hangi ortama ait olduğu, yayın kontrol listesi ve “dev'de gerçek veri yok” kuralı.\n\n## Üretim olaylarına yol açan yaygın hatalar\n\nBuradaki çoğu olay gizemli hatalar değildir. Yanlış bağlantılar: yanlış veritabanı, yanlış anahtar veya yanlış uç nokta.\n\nEn büyük tuzak ortamlar arasında paylaşılan veritabanıdır. Gerçekçi veri isteyenler için başta cazip görünür. Sonrasında sessiz bir yük haline gelir: bir test betiği kayıtları siler, bir göç erken çalıştırılır veya yeni bir alan üretim kodunun okuyamadığı bir formatta yazılır.\n\nDiğer sık görülen sebep staging'de üretim API anahtarlarının kullanılmasıdır. Ödemeler ve e-posta en büyük risklerdir. Tek bir staging checkout gerçek ücretler oluşturabilir ve bir staging e-posta testi gerçek müşterilere toplu mesaj gönderebilir. Platformunuz ortam değişkenlerini veya dağıtım başına ayrı konfigürasyonları destekliyorsa (birçok no-code platformu destekler, AppMaster dahil), anahtarları uygulamanın bir parçası değil, ortamın bir parçası olarak ele alın.\n\nWebhook karışıklığı yakın bir akrabadır. Ekipler webhook uç noktalarını tekrar kullanır, böylece hem staging hem prod aynı eventi alır. Bu, çift siparişler, tekrarlanan “hesap oluşturuldu” akışları ve çözülmesi zor destek ticket'ları yaratır.\n\nArka plan işleri ekstra dikkat ister çünkü sessizce çalışırlar. Gece senkronizasyonu, “hatırlatıcı gönder” iş akışı veya otomatik kapatma staging'den tetiklenip gerçek servisleri çağırabilir eğer kapatmayı unuttuysanız.\n\n## Yayın öncesi kontrol listesi ve sonraki adımlar\n\nYayın öncesi hızlı kontrollerle yaygın yanlış bağlantıları yakalamak istersiniz: staging'in üretim veritabanına işaret etmesi, yanlış API anahtarının yapıştırılması veya tehlikeli bir webhook'un açık kalması.\n\n10 dakikada çalıştırılabilecek hızlı kontrol listesi:\n\n- Hedef veritabanının doğru olduğunu doğrulayın (host ve veritabanı adı), ve üretim bağlantı dizgisinin prod dışına çıkmadığından emin olun.\n- Her gizli bilginin üretim için yalnızca üretimde olduğunu doğrulayın (API anahtarları, OAuth istemci gizli anahtarları, ödeme anahtarları) ve non-prod anahtarlarının üretim kaynaklarına erişemeyeceğini kontrol edin.\n- Webhook ve callback ayarlarını kontrol edin, böylece prod uç noktaları staging etkinliklerini almasın.\n- Giden mesajları doğrulayın ki testler gerçek müşterilere e-posta veya SMS göndermesin.\n- Bir staging smoke testi çalıştırın: giriş yapın, bir kayıt oluşturun, bir ana iş akışını uçtan uca çalıştırın ve loglarda üretim servislerine çağrı olup olmadığını kontrol edin.\n\nSonra bir insan kontrolü yapın: üretim erişim listesini gözden geçirin ve ihtiyaç duymayanları çıkarın. Aracınız rol tabanlı izinleri destekliyorsa, ekibiniz küçük olsa bile üretim değişiklikleri için onay adımı zorunlu kılın.\n\nBunu zaman içinde yönetilebilir tutmak için adlar ve değişkenleri standartlaştırın (DEV, STAGING, PROD) ve aylık gizli bilgi ve erişim gözden geçirmesi planlayın. Bir olay sırasında yapmak zorunda kalmaktansa düzenli yapmak daha kolaydır.\n\nAppMaster ile inşa ediyorsanız, her ortam için ayrı PostgreSQL konfigürasyonları tutabilir, auth, Stripe ve e-posta/SMS gibi modülleri her dağıtımda doğru anahtarlara yönlendirebilir ve uygulama mantığını değiştirmeden farklı hedeflere (AppMaster Cloud veya tercih ettiğiniz bulut sağlayıcıları) dağıtabilirsiniz. Daha fazla platform detayı için AppMaster'ın adresi appmaster.io.