Staging Ortamı Kurulumu: Veri Maskeleme, Erişim ve Senkronizasyon

Kötü kurulmuş bir staging iki şekilde zarar verir. Ya üretimden farklıdır ve hatayı yakalamaz; ya da üretimin birebir kopyasıdır, müşteri verisini korumasız bir sunucuda tutar ve test sırasında gerçek müşterilere sipariş e-postası gönderir. İkisini de sahada sıkça görüyoruz. Aşağıdaki adımlar WordPress başta olmak üzere PHP tabanlı web projelerinde gerçekçi, güvenli ve bakımı sürdürülebilir bir staging ortamının nasıl kurulacağını anlatıyor.

Staging’in amacı ve kapsamı

Staging, geliştiricinin bilgisayarındaki ortam değildir. Geliştirme ortamı hızlı deneme içindir; staging “bu paket üretime çıkarsa ne olur?” sorusunu yanıtlar. Dolayısıyla staging’de test edilen şey tek bir kod parçası değil, yayın paketinin tamamıdır: aynı derleme çıktısı, aynı yapılandırma şablonu, aynı dağıtım betiği. Farklı betikle kurulan staging, başka bir sistemi test eder.

Kurulumdan önce kapsamı yazılı hale getirin:

• Hangi değişiklikler staging’den geçmek zorunda? (Çekirdek, eklenti ve tema güncellemeleri, PHP sürüm değişikliği, şema değişikliği, büyük tasarım değişiklikleri.)
• Staging’e kim erişecek? Geliştiriciler, test eden iş birimi kullanıcıları, dış ajans?
• Veri ne sıklıkla ve hangi yöntemle tazelenecek?
• Staging kalıcı mı olacak, yoksa her değişiklik için geçici ortam mı açılacak?

Küçük ve orta ölçekli kurumsal siteler için kalıcı tek bir staging genellikle yeterlidir. Birden fazla ekibin paralel çalıştığı projelerde her dal (branch) için geçici ortam açan yapılar daha verimli olabilir; ama o durumda veri maskeleme ve erişim kısıtlama tamamen otomatik olmak zorundadır. Güncelleme sürecinde staging’in hangi adımda devreye alınacağını WordPress güncelleme politikası yazısında anlattık.

Üretimle ortam eşitliği

“Staging’de çalışıyordu, üretimde bozuldu” vakalarının çoğunda neden, iki ortam arasında kimsenin fark etmediği bir sürüm farkıdır. Eşit tutulması gereken katmanlar ve farkın tipik sonucu:

Katman	Eşit olmalı	Fark olursa
PHP sürümü ve eklentileri	Ana ve ara sürüm, yüklü modüller	Kaldırılmış fonksiyon, eksik modül hatası
Web sunucusu	Nginx/Apache sürümü, rewrite kuralları	Kalıcı bağlantı ve yönlendirme hataları
Veritabanı	MariaDB/MySQL sürümü, karakter seti, sql_mode	Sorgu ve sıralama farkları
Önbellek katmanı	Redis/OPcache, sayfa önbelleği	Önbellek kaynaklı hatalar gizlenir
Cron ve kuyruk	Zamanlanmış işlerin yöntemi	Arka plan işleri test edilmez

Eşitliği korumanın güvenilir tek yolu, iki ortamı aynı tanımdan üretmektir: Ansible rolü, Docker imajı ya da en azından sürümleri sabitlenmiş bir kurulum betiği. Elle kurulan iki sunucu altı ay sonra birbirinden ayrışmış olur. Kapasite farkı ise kabul edilebilir; staging’in daha az CPU ve belleği olması normaldir. Yalnızca performans testi yapacaksanız bu farkın sonuçları nasıl etkileyeceğini hesaba katın.

WordPress’te ortam tipini açıkça tanımlayın. WP_ENVIRONMENT_TYPE sabiti, wp_get_environment_type() fonksiyonu üzerinden eklentilerin ve özel kodun ortama göre davranmasını sağlar:

wp config set WP_ENVIRONMENT_TYPE staging
wp config set DISABLE_WP_CRON true --raw

WP-Cron’u kapatmak, sayfa ziyaretleriyle tetiklenen ve dış servislere istek gönderebilen zamanlanmış görevleri durdurur. Cron işlerini test etmeniz gerekiyorsa elle veya kontrollü bir sistem cron’u ile çalıştırın.

Veri kopyalama ve maskeleme

Gerçekçi test gerçekçi veri ister. Ancak üretim veritabanındaki kişisel veriyi korumasız bir test sunucusuna taşımak, 6698 sayılı KVKK’nın veri güvenliği yükümlülükleri açısından ciddi risktir. Staging sunucuları çoğu zaman daha gevşek erişim kurallarıyla, daha fazla kişinin girdiği ortamlardır. Varsayılan kural basit olmalı: veri staging’e maskelenmiş girer.

Maskeleme kopyalama sırasında ayrı bir ara adımda yapılır: üretim dökümü önce izole bir ortamda yüklenir, maskelenir, sonra staging’e aktarılır. Bir WordPress sitesi için temel maskeleme adımlarına örnek:

-- Kullanıcı e-postaları ve adları
UPDATE wp_users
   SET user_email   = CONCAT('kullanici', ID, '@example.invalid'),
       display_name = CONCAT('Kullanıcı ', ID),
       user_pass    = '';

-- WooCommerce müşteri meta verileri
UPDATE wp_usermeta
   SET meta_value = ''
 WHERE meta_key IN ('first_name','last_name','billing_first_name',
                    'billing_last_name','billing_phone','shipping_phone',
                    'billing_address_1','shipping_address_1','billing_email');

Bu bir başlangıç noktasıdır, eksiksiz liste değildir. user_login ve user_nicename alanları da çoğu sitede e-posta adresi veya gerçek ad taşır. Form eklentilerinin kayıt tabloları, sipariş tabloları (WooCommerce’ta HPOS etkinse wp_wc_orders ve ilişkili tablolar), yorumlar, CRM senkronizasyon tabloları ve log tabloları da kişisel veri içerebilir. Sahada en sık atlanan yer, eklentilerin kendi açtığı ve kimsenin hatırlamadığı tablolardır. Doğru yöntem: veritabanındaki tüm tabloların envanterini çıkarın, her tabloyu “maskele / boşalt / olduğu gibi kopyala” olarak sınıflandırın ve bu sınıflandırmayı betiğe dönüştürün. Yönetici hesaplarının parolasını boşaltmak yerine staging’e özel yeni hesaplar açın. Form verilerinin saklanmasıyla ilgili KVKK uyumlu iletişim formu yazısındaki ilkeler staging için de geçerlidir.

URL değişimi

WordPress site adresini ve içerikteki bağlantıları veritabanında tam URL olarak saklar; bir kısmı serileştirilmiş (serialized) PHP dizilerinin içindedir. Düz bir SQL REPLACE, serileştirilmiş verideki karakter uzunluklarını bozar ve widget’lar, tema ayarları sessizce kaybolur. WP-CLI’nin search-replace komutu bu veriyi doğru işler:

# Önce deneme
wp search-replace 'https://www.ornek.com.tr' 'https://staging.ornek.com.tr' \
   --all-tables-with-prefix --precise --dry-run

# Sonra gerçek çalıştırma
wp search-replace 'https://www.ornek.com.tr' 'https://staging.ornek.com.tr' \
   --all-tables-with-prefix --precise

Multisite kurulumlarda --network parametresi tüm sitelerin tablolarını işler. Ancak alan adları wp_blogs ve wp_site tablolarında şemasız (yalnız alan adı olarak) tutulur; tam URL ile yapılan değişim bunları yakalamaz, bu tabloları ayrıca güncelleyin. Elementor kullanan sitelerde değişimden sonra üretilmiş CSS dosyalarının yeniden oluşturulması gerekebilir; Elementor’un Araçlar ekranındaki CSS ve verileri yeniden oluşturma seçeneğini kullanın.

Dış entegrasyonları izole etmek

Staging’in en pahalı hatası, test sırasında gerçek dünyaya dokunmasıdır: müşteriye sipariş onay e-postası gider, ödeme sağlayıcısında gerçek işlem açılır, ERP’ye sahte sipariş düşer, pazarlama aracına test kayıtları eklenir. Her biri ayrı önlem ister:

• E-posta: Giden postayı Mailpit gibi bir yakalama aracına yönlendirin ya da tamamen engelleyin. WordPress’te pre_wp_mail filtresi (WordPress 5.7 ve sonrası) gönderimi kısa devre yaptırır. SMTP eklentisinin kimlik bilgileri staging’e hiç kopyalanmamalı.
• Ödeme: Ödeme altyapısının test (sandbox) anahtarlarını kullanın; üretim API anahtarları staging veritabanında kalmamalı.
• ERP/CRM ve webhook’lar: Entegrasyon uç noktalarını test sistemine çevirin veya kapatın. Giden webhook kayıtları veritabanında tutuluyorsa kopyadan sonra temizleyin.
• Analitik ve etiketler: GA4, reklam pikselleri ve etiket yöneticisi staging’de ya kapalı olmalı ya da ayrı bir test mülküne yazmalı; aksi halde üretim raporları kirlenir.
• Ağ düzeyinde önlem: Mümkünse staging sunucusunun dışarı çıkışını güvenlik duvarında yalnız gerekli adreslere izin verecek şekilde kısıtlayın. Uygulama ayarı unutulsa bile bu katman korur.

Bu adımların hepsi veri kopyalama betiğinin parçası olmalı. “Kopyaladıktan sonra şunları kapat” diye elle tutulan liste bir gün mutlaka atlanır. Betik atlamaz.

Erişim kısıtlama ve indeks engeli

Staging’in arama motorunda görünmesi hem yinelenen içerik sorunu yaratır hem de yayınlanmamış içeriği ifşa eder. WordPress’in “arama motorlarının bu siteyi dizine eklemesini engelle” seçeneği (wp option update blog_public 0) yalnızca bir istektir; tarayıcıyı fiilen durdurmaz. Gerçek koruma, siteye kimlik doğrulamasız erişilememesidir:

server {
    server_name staging.ornek.com.tr;

    auth_basic           "Staging";
    auth_basic_user_file /etc/nginx/.htpasswd-staging;
    add_header X-Robots-Tag "noindex, nofollow" always;
    ...
}

Parola koruması, IP kısıtlaması ve VPN arkasında yayın birlikte kullanılabilir. Bu katmanların ne zaman yettiğini ve noindex ile robots.txt arasındaki farkı indeksleme sinyalleri yazısında ele aldık. Staging için ayrı TLS sertifikası kullanın ve staging alan adının üretim çerezleriyle aynı çerez alanını paylaşmadığını kontrol edin; .ornek.com.tr gibi geniş tanımlı bir çerez alanı, üretim oturumunu staging’e taşıyabilir.

Staging’den üretime taşıma riskleri

Staging’in en çok yanlış kullanıldığı nokta, test edilen değişikliğin üretime aktarılma biçimidir. “Staging veritabanını üretime kopyalayalım” yaklaşımı, kopya alındıktan sonra üretimde oluşan tüm siparişleri, form kayıtlarını, yorumları ve kullanıcı kayıtlarını siler. Üstüne maskelenmiş veri üretime geri yazılır.

Güvenli akışın tek bir kuralı var: kod staging’den üretime, veri üretimden staging’e akar. Pratikte:

1. Kod, tema ve eklenti değişiklikleri sürüm kontrolünden ve aynı dağıtım betiğiyle üretime çıkar; kesintisiz geçiş için sıfır kesintili dağıtım teknikleri kullanılır.
2. Yapılandırma değişiklikleri (eklenti ayarları gibi) mümkünse koda veya WP-CLI komut dosyasına dönüştürülür ve üretimde aynı komutlarla uygulanır.
3. Yeni sayfa ve şablon gibi içerik değişiklikleri ya üretimde taslak olarak hazırlanır ya da tekil dışa/içe aktarma ile taşınır. URL’lerin ve medya kimliklerinin değişeceği hesaba katılır.
4. Yöntem ne olursa olsun, taşıma öncesinde üretimin dosya ve veritabanı yedeği alınır ve geri yükleme yöntemi bellidir.

Staging ortamı, maskeleme betiği ve dağıtım hattı birbirine bağlı parçalardır. Yeni bir eklenti tablosu veya yeni bir entegrasyon anahtarı geldiğinde üçü birlikte güncellenmeli. Bu yapıyı CI/CD ve web DevOps otomasyonu kapsamında kurgulayabilir; Virtualmin tabanlı sunucularda staging’i ayrı bir sanal sunucu olarak Linux VPS ve Virtualmin yönetimi çerçevesinde izole edebilirsiniz. WP-CLI parametrelerinin tam listesi için wp search-replace dokümantasyonu başvuru kaynağıdır.

Sık sorulan sorular

Staging için üretim veritabanının tam kopyasını kullanmak yasal mı?

Kişisel veri içeren bir kopyayı test ortamına taşımak KVKK kapsamında bir veri işleme faaliyetidir ve aynı güvenlik önlemlerini ister. En güvenli yol, kişisel verileri kopyalama sırasında maskelemek veya boşaltmaktır. Tam kopya gerçekten gerekiyorsa erişim, şifreleme ve saklama süresini üretimle aynı düzeyde tutun ve konuyu hukuk birimiyle değerlendirin.

robots.txt ile staging’i engellemek yeterli mi?

Hayır. robots.txt tarayıcılara yalnızca bir istektir; sayfa başka bir yerden bağlantı alırsa URL yine dizinde görünebilir. Erişimi HTTP kimlik doğrulama veya IP kısıtlamasıyla fiilen engelleyin, ek olarak X-Robots-Tag noindex başlığı gönderin.

wp search-replace komutunda –dry-run neden önemli?

Deneme modu hiçbir veriyi değiştirmeden hangi tablolarda kaç değişiklik yapılacağını listeler. Yanlış bir arama ifadesinin beklenmedik tablolara dokunup dokunmayacağını gerçek çalıştırmadan önce görürsünüz.

Staging’de yapılan Elementor tasarımını üretime nasıl taşırım?

Veritabanının tamamını kopyalamayın. İlgili şablonu veya sayfayı Elementor’un şablon dışa aktarma özelliğiyle JSON olarak alıp üretime içe aktarın. Medya kimlikleri ve global stil ayarları ortamlar arasında farklı olabilir; içe aktarmadan sonra sayfayı üretimde taslak olarak kontrol edip yayına alın.