WordPress Staging: Kurulum, Senkronizasyon ve Güvenli Geri Yükleme

Canlı sitede bir eklenti etkinleştirdiniz, sayfa beyaz oldu ve şimdi bir sonraki sefer her değişiklikten önce sitenin ayrı bir kopyasına sahip olmanın yolunu arıyorsunuz. Ya da tam tersi: bir staging kopyanız var, ancak ana siteye her yeni içerik yayınlandığında staging ortamınız eskiyor ve işe yaramaz hale geliyor. WordPress staging'de asıl mesele bir kopya oluşturmak değil; iki site arasındaki veri akışını yönetmektir.

WordPress staging'i nerede kurmalısınız: alt alan adı mı, ayrı sunucu mu

Üç gerçek seçeneğiniz var ve her birinin maliyeti ancak birkaç hafta sonra ortaya çıkar.

Siteniz günde birkaç bin görüntüleme alıyorsa, aynı hosting üzerinde alt alan adını seçmeyin. Staging'deki kötü bir eklenti, ağır bir sorguyla canlı site için bile MySQL'i kilitleyebilir. Ben pratikte, site küçük ve bütçe kısıtlı olmadıkça ayrı hosting'i tercih ediyorum.

Kurulum için önce bir alt alan adı oluşturun ve DNS kaydını yapılandırın. Bunu yeni yapıyorsanız, yeni başlayanlar için site DNS yapılandırması rehberi kayıtların sırasını ve propagation bekleme süresini açıklıyor.

Canlı siteyi bozmadan kopyasını almak

Canlı site klasörünü asla cp -r ile kopyalamayın; yarım kalmış cache ve uploads dosyalarını da beraberinde getirirsiniz. Doğru sıra şudur:

wp db export /tmp/live.sql --add-drop-table
rsync -avz --exclude='wp-content/cache' --exclude='wp-content/uploads/*' \
  /var/www/live/ stage@host:/var/www/stage/

uploads klasörünü ayrı olarak ve yalnızca gerektiğinde taşıyın. Sitenizin 2 gigabayttan fazla uploads'ı varsa, her seferinde tam transfer yaklaşık 10 ila 20 dakika sürer ve bu süre her senkronizasyonda tekrarlanır. Büyük siteler için yalnızca yeni dosyaları rsync --ignore-existing ile gönderin.

Transferden sonra staging'in wp-config.php dosyasında şu satırları değiştirin:

define('DB_NAME', 'stage_db');
define('DB_USER', 'stage_user');
define('DB_HOST', 'localhost');
define('WP_HOME', 'https://stage.example.com');
define('WP_SITEURL', 'https://stage.example.com');

WP_HOME ve WP_SITEURL değerlerini ayarlamazsanız, WordPress veritabanındaki değeri kullanır ve sizi canlı siteye yönlendirir. Bu, "staging'im çalışmıyor" sorununun en yaygın nedenidir.

Veritabanı senkronizasyonu: herkesin her şeyi bozduğu yer

İşte burada hata yapılıyor. Birileri "değişiklikleri aktarmak için" staging veritabanını canlı siteye push ediyor ve sonra görüyor ki son iki haftanın siparişleri, yeni kullanıcılar ve onaylanmış yorumların tümü silinmiş. Belirtisi de açık: yönetim panelindeki kullanıcı sayısı bir gecede düşüyor ve müşteriler "hesabımı tanımıyor" diye e-posta atıyor.

Canlı veritabanı gerçeğin kaynağıdır. Her zaman canlıdan staging'e, tersi değil. Ayarlarda veya tablo yapısında staging'den canlıya bir değişiklik taşımak zorundaysanız, bunu tam bir import ile değil, manuel olarak ve yalnızca o tablo için yapın.

Canlı veritabanını staging'e aktardığınızda mutlaka iki şeyi yapın:

1. URL'leri wp search-replace 'https://example.com' 'https://stage.example.com' --all-tables --precise ile değiştirin. --precise olmadan serileştirilmiş veriler bozulur ve widget'lar ile sayfa oluşturucu ayarları çalışmaz hale gelir.
2. E-posta gönderimini kesin. wp config set WP_ENVIRONMENT_TYPE staging ve çıktıyı yakalayan WP Mail SMTP gibi bir eklentiyle, gerçek müşterilere test e-postası gönderilmesini engelleyin.

Pratik bir not: her senkronizasyondan önce staging veritabanının yedeğini alın. Import sonrasında staging'de önemli bir değişikliğiniz olduğunu fark ederseniz, yedek olmadan sıfırdan oluşturmanız gerekir.

Canlı siteye geri yükleme: push öncesi kontrol listesi

Test bittiğinde ve değişiklikleri canlıya almak istediğinizde, yalnızca dosyaları taşıyın. Yapısal bir değişikliğiniz yoksa canlı veritabanına dokunmayın.

• Canlı dosyaların ve veritabanının tam yedeğini alın ve yedek dosyasının başka bir sunucuda da olduğundan emin olun.
• WordPress bakım modunu etkinleştirin ki kullanıcı deploy sırasında yarım kalmış bir sayfa görmesin.
• Dosyaları silip tamamen yeniden yükleyerek değil, rsync ile taşıyın.
• Transferden sonra object cache ve sayfa önbelleğini temizleyin. Bunu yapmazsanız, kullanıcılara eski sürüm gösterilir ve deploy edilmediğini düşünürsünüz.

Değişiklikleriniz tema kodu veya özel eklenti içeriyorsa, baştan Git ile çalışmanız daha iyi olur. Site dağıtımı için Git temelleri eğitimi, dosyaları manuel taşımadan sürümleri nasıl yöneteceğinizi gösterir.

Staging'de farklı olan ve testi geçersiz kılan şeyler

Staging hiçbir zaman tam olarak canlı gibi olmaz. Test sonucunu yanlış yorumlamamak için bu farklılıkları bilin:

• Veri hacmi: Staging veritabanı genellikle daha küçüktür. 500 üründe hızlı olan bir sorgu, 50.000 üründe yavaşlar.
• Trafik: Gerçek ziyaretçi olmadan önbellek ve eşzamanlılık sorununu göremezsiniz.
• CDN ve DNS: Staging CDN arkasında değilse, gerçek yükleme süresini ölçemezsiniz.
• Güvenlik eklentileri: Bazı eklentiler staging alan adında farklı davranır veya captcha'yı reddeder.

Deploy sonrasında sürpriz yaşamamak için canlı sitenin hızını öncesinde ve sonrasında ölçün. Site hız testi; sonuçları yorumlama rehberi hangi sayının gerçekten önemli olduğunu ve hangisinin normal dalgalanma olduğunu anlamanıza yardımcı olur.

Siteniz paylaşımlı hosting'deyse ve iki sürüm için yeterli kaynağınız yoksa, staging için ayrı bir Linux hosting alın. Bu, staging'deki arızalı bir eklentinin ana siteyi erişilemez hale getirmesini de önler.

Sık sorulan sorular

Staging'i canlı sitenin aynı veritabanında çalıştırabilir miyim?

Hayır, bu tehlikelidir. Her iki site de aynı veritabanına bağlıysa, staging'deki her değişiklik anında canlı siteye uygulanır ve staging kavramı ortadan kalkar. Tablo öneklerini değiştirseniz bile, ayarları wp_options içinde saklayan eklentiler çakışmaya neden olur.

Staging'in canlı siteden doğru şekilde ayrıldığını nasıl anlarım?

Üç şeyi kontrol edin: wp-config.php içindeki WP_HOME değeri, veritabanı adı ve arama motorunun indekslememesi. Son madde için okuma ayarlarında "arama motorlarını caydır" seçeneğini etkinleştirin veya X-Robots-Tag: noindex başlığını ekleyin. Bunu yapmazsanız, staging sürümü Google sonuçlarında görünür ve yinelenen içerik oluşturur.

Veritabanı senkronizasyonundan sonra görseller neden görünmüyor?

Genellikle eksik search-replace yüzündendir. Eski URL meta tablolarında veya serileştirilmiş dosyalarda kalmışsa, görsel yolları bozulur. wp search-replace komutunu --precise bayrağıyla yeniden çalıştırın ve ardından wp_options tablosunu eski alan adını içeren anahtarlar için kontrol edin.

Staging'i canlı siteyle ne sıklıkla senkronize etmeliyim?

Her önemli değişiklikten önce, sabit bir programa göre değil. Sitenizin içeriği haftalık güncelleniyorsa, haftalık senkronizasyon mantıklıdır. Ancak günde birkaç yazı yayınlıyorsanız, her seferinde tam senkronizasyon pahalıya gelir; bu durumda yalnızca içerik tablolarını senkronize edin ve kullanıcılar ile siparişler tablolarına dokunmayın.

Her deploy öncesinde geri yüklenebilir bir yedeğiniz olsun ve siteyi on dakikadan kısa sürede önceki durumuna döndürebildiğinizden emin olun. Bu testi yapmadıysanız, staging'iniz yalnızca bir test ortamıdır, bir güvenlik ağı değil.