Test ortamı canlı ortam gibi davranmalı, canlı ortam gibi risk taşımamalı
Test ortamının amacı gerçek hayata yakın test yapmaktır. Ama bunun yolu canlı ortam verisini olduğu gibi kopyalayıp herkese açmak değildir. Gerçek isim, e-posta, telefon, adres, ödeme referansı veya destek notu test ortamında duruyorsa artık test ortamı değil, ikinci bir canlı ortam riski yaratmış olursunuz.
İyi test ortamı akışı üç şeyi birlikte çözer: veri şekli canlı ortama benzer, hassas değerler maskelenir, erişim canlı ortamdan daha gevşek değil daha kontrollüdür.
- Test ortamı bağlantı dizesi canlı ortamdan isim, gizli değer ve ağ olarak ayrılmalı.
- Gerçek kişisel veri maskelenmeden test ortamına taşınmamalı.
- Geliştirici rolü canlı ortamda geniş, test ortamında sınırsız olmamalı; roller ayrı tasarlanmalı.
- Test ortamı geri yükleme işlemleri denetim ve süreli saklama politikasıyla izlenmeli.
En tehlikeli hata yanlış bağlantı dizesidir
Bir göç, seed veya yük testi scriptinin yanlışlıkla canlı ortam veritabanına bağlanması çoğu ekibin kâbusudur. Bunu sadece dikkatle önleyemezsiniz; ortam adları, gizli değer ayrımı, ağ kısıtı ve kullanıcı yetkisi birlikte çalışmalıdır.
Ortam ayrımı için bağlantı dizesi kontrolü
const databaseUrl = process.env.DATABASE_URL || ""
const appEnv = process.env.APP_ENV || "development"
if (appEnv !== "production" && databaseUrl.includes("prod")) {
throw new Error("Canlı olmayan ortam canlı veritabanına bağlanamaz")
}
if (appEnv === "production" && databaseUrl.includes("staging")) {
throw new Error("Canlı uygulama test veritabanına bağlanamaz")
}Bu kontrol tek başına yeterli değildir ama erken uyarı sağlar. Asıl güvenlik, ayrı gizli değer, ayrı kullanıcı ve ayrı ağ politikasıyla gelir.
Maskeleme veri tipine göre yapılır
Her alan aynı şekilde maskelenmez. E-posta benzersiz kalabilir ama gerçek kişiye gitmemelidir. Telefon tamamen sahte olabilir. Adres çoğu testte gerekli değildir. Ödeme referansları ve kimlik benzeri alanlar özel dikkat ister.
Maskeleme sonrası uygulama hâlâ çalışmalıdır. Benzersiz indeksler bozulursa test ortamı gerçekçi olmaktan çıkar; bu yüzden maskeleme scripti hem gizlilik hem veri bütünlüğü açısından test edilmelidir.
PostgreSQL basit maskeleme fikri
UPDATE users
SET
email = concat('user+', id, '@example.test'),
phone = NULL,
full_name = concat('Test User ', id)
WHERE email NOT LIKE '%@example.test';
UPDATE customer_addresses
SET
line1 = 'Masked address',
line2 = NULL,
postal_code = '00000';Geri yükleme veya fork sonrası ilk iş erişimi kısmaktır
Canlı ortam yedeğinden test ortamı oluşturduğunuzda verinin yaşam döngüsü değişir. O kopyanın kim tarafından görülebileceği, ne kadar süre saklanacağı ve ne zaman silineceği ayrıca tanımlanmalıdır.
TürkDB ile geri yükleme/fork benzeri akışlar pratikleştiğinde bu disiplin daha da önem kazanır. Kolay kopya almak, kontrolsüz kopya almak anlamına gelmemelidir.
Test ortamı geri yükleme sonrası kontrol
turkdb backup list app-prod-pg turkdb cluster pitr restore app-prod-pg \ --time "2026-06-14T09:00:00Z" \ --name app-staging-pg turkdb cluster allowlist list app-staging-pg turkdb cluster allowlist add app-staging-pg 198.51.100.20 --desc "VPN test ortamı erişimi" turkdb audit list --cluster app-staging-pg --limit 50
Test ortamı verisi de yaşam döngüsüne sahip olmalı
Test ortamı verisi çoğu zaman unutulur. Eski canlı ortam kopyaları aylarca durur, kimse hangi müşterinin verisinin içeride olduğunu hatırlamaz. Bu durum hem güvenlik hem maliyet riskidir.
Test ortamı clusterları etiketlemek, saklama süresi vermek ve periyodik silme kontrolü yapmak küçük ama güçlü bir alışkanlıktır. Test ortamı üretime yakın olmalı, üretim kadar kalıcı olmamalıdır.