cPanel WordPress Staging: Kurulum ve Canlıya Geçiş

WordPress Staging Ortamı Nedir ve Neden Kurmalısınız?

WordPress sitenizde tema değişikliği, büyük bir eklenti güncellemesi ya da özel bir geliştirme yapmanız gerektiğinde, bunu doğrudan canlı sitede denemek ciddi risk taşır. Tek bir hatalı eklenti veya kod parçası; ödeme sayfanızın çalışmaması, formların bozulması veya sitenizin tamamen erişilemez hale gelmesiyle sonuçlanabilir. Bu riskleri azaltmanın etkili bir yolu, canlı sitenizin yapısını mümkün olduğunca yansıtan bir WordPress staging ortamı kurmaktır; ancak staging testleri canlı ortamda sorunsuz çalışmayı garanti etmez.

Staging kopyasında bir eklenti değişikliğinden sonra hata oluşursa “WordPress Eklenti Çakışması: Hızlı Teşhis ve Geri Alma” rehberi, sorumlu bileşeni ayırma ve güvenli geri alma adımlarını açıklar.

Staging, canlı siteden ayrı yapılandırılan test kopyasıdır. Erişimi, veritabanı bağlantısını ve dış servislerini ayrıca ayırmadan güvenli kabul edilemez. Bu rehber tek site WordPress kurulumu için güncel cPanel Domains akışını, dosya/DB klonlamayı ve kontrollü dağıtımı açıklar. Multisite, özel sunucu yerleşimleri ve eklentiye özgü taşıma işlemleri ayrı plan gerektirir. Test başarısı canlı ortamda sorunsuz çalışma garantisi değildir.

Bu yazının odağı ilk kurulum, test sınırları ve canlı kayıtları koruyan yayınlamadır. Mevcut kopyayı yeniden üretimden doldurma, kişisel veri maskeleme ve araçların veri sahipliği için ayrı WordPress staging yenileme rehberini izleyin.

Staging Ortamı Kurmadan Önce Planlama: Alan Adı, Hosting ve Kaynaklar

Teknik adımlara geçmeden önce, staging ortamınızı nereye ve nasıl kuracağınıza karar vermeniz gerekir. Bu planlama aşaması, ileride karşılaşabileceğiniz pek çok sorunu baştan çözer.

Alt alan adı mı, alt dizin mi?

Staging için en sık kullanılan yöntem, alt alan adı (subdomain) kullanmaktır. Örneğin:

• Canlı site: example.com
• Staging: staging.example.com veya test.example.com

Alternatif olarak example.com/staging gibi bir alt dizin de kullanabilirsiniz; ancak SSL ve yönlendirme ayarlarını ayrı yönetmek açısından alt alan adı genellikle daha elverişlidir. Aynı hosting hesabındaki bir alt alan adı, tek başına dosya erişimi veya kaynak kullanımı bakımından güvenlik izolasyonu sağlamaz. Zaten alt alan adları ile alt dizinleri karşılaştırdığımız subdomain mi alt dizin mi rehberimizde de, staging gibi test ortamlarında alt alan adının çoğu senaryoda daha mantıklı olduğunu vurguluyoruz.

Hangi hosting türü daha uygun?

Paylaşımlı hosting veya WordPress hosting planında alan adı, disk ve DB kotaları uygunsa aynı hesapta staging kurulabilir. Ancak aynı kullanıcı izinleri, kaynak bütçesi veya paylaşılan cache/DB hizmetleri iki ortamı etkileyebilir. Bağımsız müşteri veya hassas testlerde ayrı hesap/ortam değerlendirin. VPS/dedicated seçeneğinde cPanel lisansı, yönetim ve gerçek kapasiteyi ayrıca doğrulayın.

Kaynak planlaması ve limitler

Diskte yalnız ikinci siteye değil SQL dışa aktarımları, arşivler, açılmış dosyalar ve yedekler için de alan gerekir. Hassas canlı veriyi teste taşımadan önce gereksiz kişisel veriyi çıkarın veya uygun biçimde maskeleyin; test kopyasının erişim ve saklama sorumluluğu devam eder.

• Disk alanınızın staging kopyayı da taşıyacak kadar yeterli olduğundan emin olun.
• cPanel’deki CPU, RAM ve IO limitlerini gözden geçirin; yoğun testler sırasında anlık limit aşımlarını önlemek için cPanel kaynak limitleri rehberimize göz atabilirsiniz.
• Veri kaybını önlemek için, staging kurulumu öncesinde mutlaka sağlam bir yedekleme stratejisi tasarlayın. Bu konuda detaylar için WordPress yedekleme stratejileri rehberimizi incelemenizi öneririz.

cPanel’de Staging İçin Alt Alan Adı (Subdomain) Oluşturma

Aşağıdaki yol cPanel 138 ve sonraki güncel belgelere dayanır; gerçek panel sürümü, dil ve sağlayıcının etkinleştirdiği özellikleri kontrol edin. Ayrı eski Subdomains ekranı yerine Domains kullanılır. Bir alt alan adı oluşturmak yeni bir alan adı kaydı satın almak anlamına gelmez.

1. cPanel’e giriş yapın

Sağlayıcınızın doğruladığı cPanel giriş adresini kullanın. Domains, veritabanı ve dosya araçlarına yetkiniz olduğunu kontrol edin; menünün görünmemesi yeni bir hesap veya plan yetkisi gerektirebilir.

2. Alt alan adı oluşturun

1. cPanel → Domains → Create a New Domain yolunu açın; sunuluyorsa Registered Domain türünü seçin.
2. Domain alanına yalnız staging ya da test öneki yerine, seçtiğiniz önekle tam alt alan adını yazın; örneğin staging.example.com.
3. Share document root seçimini kaldırarak canlı siteden farklı, boş bir document root belirleyin.
4. public_html/staging örnek bir konumdur. Güncel arayüz belgesi public_html dışındaki köklere izin vermez; panelin izin verdiği gerçek yolu doğrulayın. İç içe dizin, canlı hostname üzerinden de erişilebilir olabileceğinden iki erişim yolunu birlikte koruyun.
5. Submit ile oluşturun ve Domains listesinde tam alan adı ile kök dizini tekrar kontrol edin. Aynı hesabın ayrı klasörü bağımsız kullanıcı izolasyonu sağlamaz.

staging.example.com için panel eşlemesi, genel DNS’nin doğru olduğu anlamına gelmez. Kaydı gerçekten yetkili DNS hizmetinde oluşturun; A kaydı doğru IPv4’e, gerekiyorsa AAAA çalışan IPv6’ya işaret etmelidir. DNS dışarıdaysa yalnız cPanel Zone Editor’ı değiştirmek yetmez. Sırf staging için ana domain’in nameserver’larını değiştirmeyin; alt bölge önceden devredilmişse o yetkili bölgede işlem yapın. Web kaydı eklemek posta hesabı veya güvenli test e-postası yapılandırması oluşturmaz.

3. SSL sertifikasını kontrol edin

Staging ortamında da HTTPS kullanmak önemlidir. Böylece hem canlı ortama daha yakın bir yapı kurar hem de karışıklıkları önlersiniz.

1. Security → SSL/TLS Status ekranını veya birleşik SSL/TLS Certificates içindeki ilgili sekmeyi açın.
2. Staging hostname’ini kapsayan güvenilir, geçerli sertifikayı kontrol edin. Ana alan adının sertifikası alt alan adını kendiliğinden kapsamaz; mevcut sertifika uygun adları içeriyorsa kullanılabilir.
3. Hesapta AutoSSL etkinse otomatik talep/kurulum durumunu ve hatalarını izleyin; mevcut çalıştırma seçeneği veya sağlayıcının sürecini kullanın. Talep, başarılı düzenleme veya sabit süre garantisi değildir.
4. DNS ve sertifika doğrulama gereksinimlerini çözün; test içeriğini herkese açmayın. HTTPS üzerinden gerçek hostname ve sertifika zincirini doğrulayın. Kendinden imzalı sertifikanın görünmesi tarayıcı güveni anlamına gelmez.

SSL ve HTTPS tarafını daha derinlemesine anlamak isterseniz, SSL sertifikası nedir ve nasıl güvence sağlar başlıklı yazımız da işinize yarayacaktır.

WordPress Dosya ve Veritabanını Staging Ortamına Klonlamak

Önce boş hedefe erişim korumasını kurun ve doğrulayın; ilerideki Directory Privacy bölümünü bu aşamada uygulayın. Klonlama boyunca PHP, CLI, cron ve kuyruk işlerinin kopyayı çalıştırmasını önleyin. Dosyalarla birlikte gelen canlı DB, SMTP, ödeme ve API kimlik bilgileri ayrı test karşılıklarıyla değiştirilmeden WordPress’i başlatmayın. WP_ENVIRONMENT_TYPE için staging değeri tanımlamak tek başına bu bağlantıları kapatmaz.

1. Staging kurulumu öncesi eksiksiz yedek alın

Canlı sitenizde yapacağınız her ciddi işlemde olduğu gibi, staging kurulumu öncesinde de mutlaka tam yedek alın:

• WordPress dosyaları, gizli yapılandırmalar ve gerekli web kökü dışı dosyalar.
• Uygulamanın tüm veritabanı tabloları; kullanılan depolama motoruna uygun tutarlı dışa aktarım.
• Harici medya, entegrasyon yapılandırmaları ve geri yükleme için gereken erişim/şifreleme bilgileri; bunları ayrı koruyun.

cPanel Backup Wizard, dosya araçları ve phpMyAdmin farklı kapsamları yedekler. Değişen dosya ve DB için koordineli snapshot veya gerekli yazımları durdurma planı yapın; tek tek farklı anlarda alınan kopyaları otomatik tutarlı saymayın. Tam hesap yedeğini otomatik geri yüklemek WHM/sağlayıcı yetkisi gerektirebilir. Şifreli aktarım, kaynak dışı kopya ve yalıtılmış geri yükleme testiyle WordPress yedekleme rehberindeki yöntemleri tamamlayın.

2. WordPress dosyalarını staging dizinine kopyalayın

Varsayalım canlı siteniz public_html altında kurulu ve staging için public_html/staging dizinini kullanacaksınız. Dosyaları kopyalamadan önce staging dizinine yetkisiz erişimi engelleyin; korumanın hem alt alan adından hem de canlı alan adındaki /staging yolundan yapılan isteklerde geçerli olduğunu kontrol edin. Kopyalanan yapılandırma başlangıçta canlı veritabanı bilgilerini taşıyacağından, ayrı staging veritabanı bağlantısı ve URL ayarları tamamlanmadan staging üzerinden WordPress’i çalıştırmayın. Testlere başlamadan önce canlı ödeme, e-posta ve webhook bağlantılarını devre dışı bırakın veya test karşılıklarına yönlendirin.

1. Dosya Yöneticisi’nde gizli dosyaları gösterin; kaynak ve hedefi teyit edin.
2. public_html içindeki gerekli wp-admin, wp-content, wp-includes ve diğer dosyaları seçin. Staging hedefini, eski yedekleri ve arşivleri dışlayın.
3. .zip arşivini, örneğin site.zip, web üzerinden erişilemeyen özel konumda oluşturun. Canlı yapılandırma sırları içerebilir.
4. site.zip arşivini mümkünse özel konumdan açıp hedefi public_html/staging olarak seçin; araç buna izin vermiyorsa şifreli aktarım veya sağlayıcının desteklediği yöntemle korumalı hedefe kopyalayın.
5. public_html/staging altında fazladan iç içe dizin oluşmadığını kontrol edin. Kaynaktaki yönlendirme ve kimlik doğrulama dosyalarını körlemesine uygulamayın; yeni erişim korumasını ezmiş olabileceğinizi varsayarak tekrar sınayın.
6. Kullanılan site.zip dahil geçici kopyaları denetleyin. WordPress’i açmadan DB/URL/test servislerini ayırın. Web erişimi olabilen geçici arşivleri kaldırın; bağımsız üretim yedeğini özel konumda koruyun.

Alternatif olarak yetkili SFTP/FTPS erişimi kullanılabilir. Hız dosya sayısı, sıkıştırma ve hesap limitlerine bağlıdır; yedekleri veya parolaları herkese açık URL’de bırakmayın.

3. Yeni bir veritabanı ve kullanıcı oluşturun

Staging ortamınızın canlı siteyle aynı veritabanını kullanmasını istemeyiz; çünkü staging’de yaptığınız değişiklikler canlı veriyi etkileyebilir. Bu yüzden staging için ayrı bir veritabanı ve kullanıcı oluşturuyoruz.

1. cPanel → Databases → Manage My Databases ekranını açın. 118 ve önceki sürümlerde adı MySQL Databases idi; mevcut etiketi panel sürümüyle doğrulayın. DB ve kullanıcıyı phpMyAdmin’de oluşturmayın; cPanel eşlemesi/yedekleme kapsamı bozulabilir.
2. New Database alanında örneğin staging_db oluşturun; panelin eklediği kullanıcı önekini içeren tam adı kaydedin.
3. Yeni, yalnız staging için staging_user kullanıcısı ve benzersiz parola oluşturun.
4. Add User To Database ile yalnız yeni staging DB’sine bağlayın. WordPress kurulum/güncellemesi için gereken yetkileri bu veritabanında verin; ALL PRIVILEGES seçimi sunucu geneli yetki vermek değildir. Canlı DB’ye erişimi olmadığını doğrulayın.

4. Canlı veritabanını dışa aktarın

1. Canlı kurulumun hangi DB ve tablo önekini kullandığını yapılandırmadan doğrulayın; parolayı paylaşmayın.
2. phpMyAdmin’de doğru canlı DB’yi seçin, Export → SQL yolunu kullanın.
3. Gerekli tüm tabloları ve uygulama verilerini kapsayan ayarları doğrulayın. Quick her büyük/özel DB için uygun veya atomik snapshot demek değildir.
4. Aktif yazımlar varsa tutarlı dışa aktarım planını uygulayın; özel SQL dosyasını güvenli konumda tutun. Büyük DB’de süre/bellek sorunu için desteklenen yedekleme/komut satırı yöntemini değerlendirin.

5. Veritabanını staging veritabanına içe aktarın

1. Yeni, ayrı staging DB’sini seçip adını tekrar kontrol edin.
2. Import sekmesinde SQL dosyasını seçin; dosyada başka DB’yi hedefleyen USE/CREATE DATABASE veya beklenmeyen işlemler bulunmadığını inceleyin.
3. Dosya boyutu, karakter kümesi ve sunucu sınırlarına uygun ayarlarla aktarın; hata veya yarım aktarımı başarı saymayın.
4. Beklenen tabloları ve örnek veri bütünlüğünü doğrulayın. Canlı DB’ye import yapmayın.

Staging DB’si doğruladığınız dışa aktarım anını temsil eder; canlı sitede sonra oluşan kayıtları içermez. İçe aktarım tamamlandıktan sonra gereksiz kişisel veriyi maskeleyin ve kopyadaki gerçek müşteri iletişim/entegrasyon ayarlarını güvenli test değerlerine dönüştürün.

6. wp-config.php dosyasını staging veritabanına göre güncelleyin

Kopya çalıştırılmadan önce staging yapılandırmasını yeni DB’ye bağlayın. Canlı yapılandırmayı include eden özel kod, harici sır kaynağı, paylaşılan tablo, cache ve dosya yollarını da inceleyin; yalnız üç sabiti değiştirmek bütün bağımlılıkları ayırmayabilir.

1. cPanel Dosya Yöneticisi ile public_html/staging dizinine girin.
2. wp-config.php dosyasını bulun ve “Düzenle” butonuna tıklayın.
3. Aşağıdaki satırları staging veritabanına göre güncelleyin:

define( 'DB_NAME', 'cpanelkullanici_staging_db' );
define( 'DB_USER', 'cpanelkullanici_staging_user' );
define( 'DB_PASSWORD', 'BURAYA_GUCLU_SIFRE' );

DB_HOST değerini sağlayıcının gerçek DB sunucusu bilgisiyle doğrulayın; aynı sunucuda localhost olabilir, uzak DB’de farklıdır. Tablo öneki kopyalanan tablolarla eşleşmelidir. Staging’e ait oturum/salt anahtarları ve test servisleri kullanın; yalnız kopyanın yapılandırmasını değiştirin.

7. Site URL ve WordPress URL bilgisini güncelleyin

Veritabanınız hâlâ canlı alan adını işaret ediyor olacaktır. Bu nedenle staging veritabanındaki URL’leri staging alt alan adınıza çevirmemiz gerekir.

Seçenek 1: wp-config.php ile geçici çözüm

Ayrı DB ve test bağlantıları hazırlandıktan sonra yalnız staging wp-config.php dosyasına aşağıdaki örnek değerleri uyarlayabilirsiniz. Önceden tanımlı sabitleri iki kez tanımlamayın; çekirdek farklı dizindeyse home ve siteurl aynı olmak zorunda değildir.

define( 'WP_HOME', 'https://staging.example.com' );
define( 'WP_SITEURL', 'https://staging.example.com' );

Bu sabitler home/siteurl değerlerini çalışma sırasında geçersiz kılar; DB’deki değerleri veya içerikteki bütün URL’leri değiştirmez. Sabitler kaldırılırsa DB’deki eski ayarlar yeniden etkili olabilir. İç bağlantı, medya, yönlendirme ve harici endpoint’leri ayrıca denetleyin.

Seçenek 2: Veritabanında arama-değiştirme

Staging DB’sinin ayrıca yedeğini alıp PHP serialize verisini anlayan araçla kapsamı belirlenmiş arama-değiştirme yapın. Önce değişiklik yazmayan önizlemeyi inceleyin; canlı bağlantısı kalmış bir kurulumda aracı çalıştırmayın. Seçenekler:

• Güvenilir bir “search-replace” eklentisiyle,
• veya WP-CLI kullanabiliyorsanız komut satırından

Örneğin https://example.com yerine https://staging.example.com kullanılır; gerçek protokol, www ve kurulum yollarına göre eşlemeleri belirleyin. WP-CLI’de doğru staging yolu/DB’sini ve ilgili tabloları seçip –dry-run raporunu okuyun; tüm sunucu DB’lerinde körlemesine değiştirme yapmayın. GUID gibi kalıcı tanımlayıcıları ve değiştirilmemesi gereken harici adresleri kapsam dışında bırakın. Eklenti/özel tabloların da işlenip işlenmediğini doğrulayın.

Staging Ortamını Güvenli Hale Getirmek: Şifreleme, Erişim ve SEO

Gizlilik önlemlerini klonlamadan önce uygulayın; bu bölüm adımları ayrıntılandırır. Staging’in aramada görünmesi yanlış URL’lerin seçilmesine yol açabilir; sırf bir kopya olması otomatik SEO cezası anlamına gelmez. Öncelik gerçek erişim kontrolüdür; indeksleme yönergeleri bunun yerine geçmez.

1. Staging ortamını parola ile koruyun (HTTP Basic Auth)

Directory Privacy, desteklenen web yapılandırmasında seçilen dizine HTTP kimlik doğrulaması ekler. HTTPS ile kullanın. FTP/SFTP, yerel dosya erişimi veya aynı kullanıcıyla çalışan kodu engellemez; Nginx/CDN/özel kurulumlarda gerçek erişim yollarını ayrıca test edin.

1. cPanel’de Directory Privacy (Dizin Gizliliği) menüsünü açın.
2. public_html/staging dizininin düzenleme ekranını açın; gerçek hedef kökle eşleştiğini kontrol edin.
3. Password protect this directory seçeneğini etkinleştirin, korumalı dizin adını belirleyin ve Save ile kaydedin.
4. Create User bölümünden yetkili kişi için ayrı kullanıcı adı ve güçlü parola oluşturup kaydedin. Parolaları açık kanallarda paylaşmayın.

Oturum açmamış ayrı istemciden PHP sayfasını, statik dosyayı ve varsa canlı hostname altındaki staging yolunu deneyin; içerik korumayı aşmamalıdır. Kopyalama veya yönlendirme değişimi korumayı bozabilir. Sertifika doğrulamasını gerekli yöntemle çözün, bütün staging’i herkese açmayın. Ekip erişimini bireysel yetki ve parolalarla sınırlayın.

2. Arama motorlarına staging’i indekslememelerini söyleyin

WordPress kontrol panelinizden:

1. Ayarlar → Okuma menüsüne gidin.
2. “Arama motorlarının bu siteyi indekslemesini engelle” seçeneğini işaretleyin.
3. Değişiklikleri kaydedin.

Güncel WordPress bu tercihi robots meta noindex yönergesinde kullanır; gerçek HTML çıktısını kontrol edin. Eski sürümlerde robots.txt davranışı farklıydı. robots.txt içinde Disallow: / taramayı sınırlayan bir talimattır, gizlilik veya URL’nin indeksten çıkma garantisi değildir. Google’ın noindex’i görebilmesi için sayfayı tarayabilmesi gerekir; robots engeli bunu önleyebilir. Hassas kopyayı sırf noindex okunsun diye açmayın; erişim korumasını sürdürün. Bu ayarları üretime taşımayın.

3. SSL, güvenlik ve güncelleme politikaları

Staging ortamınız da sonuçta gerçek bir WordPress kurulumu. Bu nedenle:

• Staging hostname’ini kapsayan TLS ve yenileme durumunu kontrol edin.
• WordPress güvenlik kontrol listesini test ortamının farklı sır, veri ve erişim ihtiyaçlarına göre uygulayın.
• cPanel güvenlik rehberindeki önerileri yetkiniz ve kurulu servislerle değerlendirin; hesapta yapılan ortak bir değişikliğin canlı siteyi etkileyebileceğini unutmayın.

Staging Ortamında Çalışma: Test, Optimizasyon ve Onay Süreci

Yetkisiz erişim, canlı DB bağlantısı, dış servisler ve otomatik işler için kontroller tamamlandıktan sonra testlere başlayın. HTTP koruması CLI/cron’u durdurmaz; kopya planlanmış işler ve gerçek API anahtarları içeriyor olabilir.

1. Güncelleme ve değişiklikleri staging’de uygulayın

Canlı sitede uygulamak istediğiniz tüm değişiklikleri önce staging’de deneyin:

• WordPress çekirdek güncellemeleri
• Tema ve eklenti güncellemeleri
• Yeni eklenti kurulumu
• Tema değişikliği veya tasarım revizyonu
• Özelleştirilmiş kod (functions.php, özel eklenti vb.)

Form, giriş, üyelik ve ödeme akışlarını test hesabı ve ödeme sağlayıcısının sandbox/test modu ile sınayın. E-posta yakalama servisi kullanın; wp_mail’i kapatmak bağımsız SMTP veya harici API gönderimlerini tek başına engellemez. Webhook, stok, fatura ve kuyruk entegrasyonlarının üretime işlem göndermediğini doğrulayın.

2. Performans ve cache ayarlarını staging’de inceleyin

Staging’de PHP, cache ve DB ayarlarını ancak değişikliğin etki sınırını biliyorsanız test edin. Aynı hesap/sunucudaki global ayarlar canlı siteyi de etkileyebilir; Redis/Memcached için ayrı erişim ve anahtar alanı kullanın. Sadece bir önek eklemek erişim kontrolü değildir. Örneğin:

• PHP versiyonunuzu yükseltmek
• OPcache, Redis, Memcached gibi bileşenleri devreye almak
• MySQL/MariaDB ayarlarını iyileştirmek

WordPress sunucu optimizasyon rehberindeki önerileri kurulu sürüm ve yetkinizle değerlendirin. Aynı veri, yazılım sürümü ve cache davranışını olabildiğince eşleyin; staging ölçümü canlı trafik altındaki performansı garanti etmez. WP-Cron ziyaretlerde zamanı gelen işleri kontrol eder; ziyaret tetiklemesini kapatmak harici cron, CLI veya ayrı kuyruk çalışanını durdurmaz. Test işleri yalnız kopya kaynakları ve güvenli servisleri kullanırken kontrollü çalıştırılmalıdır.

3. Geliştirme ekibiyle ortak bir staging süreci kurgulayın

Özellikle ajanslar, freelance geliştiriciler veya şirket içi yazılım ekipleriyle çalışıyorsanız, staging ortamı iş akışınızın merkezinde olmalıdır. DCHost blogda detaylı anlattığımız WordPress’te geliştirme–staging–canlı yolculuğu rehberinde de vurguladığımız gibi, her değişiklik staging’de test edilip onaylandıktan sonra canlıya alınmalıdır. Böylece hem geliştirici ekip hem de iş birimi tarafı, canlıya çıkmadan önce aynı ortam üzerinde test ve onay verebilir.

Staging’den Canlı Siteye Güvenli Yayına Alma Stratejileri

Staging’de her şey yolunda görünüyor; peki sırada ne var? Şimdi bu değişiklikleri güvenli ve mümkünse kesintisiz şekilde canlı ortama taşımanız gerekiyor. Burada izleyeceğiniz yol, sitenizin türüne ve değişikliklerin kapsamına göre değişebilir.

1. Veritabanı değişikliği gerektirmeyen dosya dağıtımı

Dosya dağıtımı ancak değişikliğin DB migrasyonu, ayar kaydı veya uyumsuz veri yazımı gerektirmediği doğrulanırsa dosya odaklı ele alınabilir. Tema/eklenti güncellemesi ve yeni eklenti kurulumu DB’yi değiştirebilir; sadece dosya yüklenmiş olmasını DB değişmedi kanıtı saymayın.

• wp-content altında yalnız test edilen sürümlere ait hedef dosyaları ve gerekliyse kontrollü silmeleri belirleyin; tüm klasörü eski staging kopyasıyla ezmeyin.
• Canlı yüklemeleri, DB/parolaları, ortam ayarları, erişim koruması ve indeksleme tercihini koruyun.
• Dosya/DB sürüm uyumunu, cache temizliğini ve geri dönüşü önceden planlayın; gerekli migrasyonu ayrıca uygulayın.

Değişmeyen canlı DB’yi korumak yeni siparişleri ezmeyi önler; uygulama kodunun bunları doğru işleyeceğini yine test etmelisiniz. Aynı test edilmiş sürümleri dağıtın, daha yeni bir paketi otomatik eşdeğer saymayın.

2. Veritabanı değişiklikleri yapıldıysa (yeni sayfalar, ayarlar, form yapıları vb.)

Eğer staging ortamında yeni sayfalar oluşturdunuz, sayfa yapıları değiştirdiniz veya kompleks eklentilerin ayarlarıyla oynadıysanız, iş biraz daha dikkatli olmayı gerektirir. Çünkü staging’deki veritabanı, staging kurulduğu andaki canlı veritabanının kopyasıdır; aradan geçen sürede canlı sitede yeni yorumlar, siparişler, üyelikler eklenmiş olabilir.

Öncelik, canlı veriyi kaynak kabul edip yalnız gerekli tasarım/ayar değişikliğini bağımlılıklarını bilen bir araç veya sürümlü migrasyonla aktarmaktır. Tam DB değişimi ancak aşağıdaki koşullar sağlanabiliyorsa düşünülebilir:

• Son tutarlı kopya alınmadan önce yeni sipariş, form, yönetici düzenlemesi, webhook, cron ve kuyruk gibi ilgili bütün yazım kaynaklarını gerçekten durdurun.
• Bu güncel kopyaya önceden denenmiş değişiklikleri yeniden uygulayın; veri/ID ilişkilerini ve üretime ait URL, kimlik bilgisi, mail/ödeme/cron ayarlarını doğrulayın.
• Geçiş sonuna kadar yazım duruşunu sürdürün; tutarlı son yedek, doğrulama ve geri dönüş planı olmadan DB’yi değiştirmeyin. Bakım sayfası tek başına yazım kilidi değildir.

Düşük trafik veya kısa bekleme, veri kaybı olmayacağını kanıtlamaz. WooCommerce siparişleri, ödeme mutabakatı, stok ve kullanıcı ilişkileri birden fazla tablo/hizmete yayılabilir; seçili tablo kopyalamak ya da birkaç siparişi elle eklemek güvenilir genel bir birleştirme yöntemi değildir. Canary/blue-green trafik yönetimi DB birleştirmesini kendiliğinden çözmez.

3. Dosya + veritabanı birlikte taşınacaksa

Kimi zaman staging’de hem tema/eklenti dosyalarını hem de veritabanını değiştirmeniz gerekir. Örneğin:

• Yeni bir sayfalar bütünü tasarladınız (Ödeme akışı, kampanya sayfaları vb.)
• Form eklentinizi tamamen yenilediniz ve formları baştan kurdunuz.
• Çok dilli yapı (multilingual) veya WooCommerce yapılandırmasına dair ciddi değişiklikler yaptınız.

Bu durumlarda canlıya geçiş için güvenli bir yol haritası oluşturun:

1. Test edilmiş dağıtım paketini, gerekli DB migrasyonlarını ve kapsamlı güncel geri yükleme noktasını hazırlayın.
2. İhtiyaç varsa gerçek yazım kaynaklarını durdurun; eski staging DB’sini otomatik olarak canlıya import etmeyin.
3. Canlı dosya/ayar/veri sahipliğini koruyarak yalnız planlı değişiklikleri uygulayın. Tam DB değişiminde önceki bölümün güncel kopya ve yazım duruşu koşullarını sağlayın.
4. Üretim URL’leri, sırlar, ödeme/mail/cron hedefleri ve arama görünürlüğünü doğrulayın; staging’in noindex/parola ayarlarını yanlışlıkla taşımayın.
5. Trafiği açmadan yetkili kontrollü test yapın; sonra akışları ve yeni yazımları izleyin. Geçişteki hatada yeni verileri koruyan geri dönüş/ileri düzeltme yolunu kullanın.

3-2-1 yedekleme stratejisi kaynak dışı kopyalar için temel sağlar. Geri yükleme süresi ve uygulama tutarlılığı ayrıca test edilmelidir. Önceki DB’ye dönmek yedekten sonra oluşmuş yazımları kaybettirebilir; ödeme sağlayıcısında tamamlanmış işlemleri geri almaz.

Staging Ortamının Sürekli Bakımı

Test ortamını güncel envanter, sınırlı erişim ve belirli saklama süresiyle yönetin. Hizmet kapsamı ve otomasyon seçeneklerini seçilen hosting planıyla doğrulayın.

Aynı hesapta birden fazla staging ortamı

Bir hesapta birden fazla test kopyası kullanılıyorsa sabit bir güvenli adet yoktur; disk, DB, işlem bütçesi ve ortak kullanıcı riski birlikte değerlendirilmelidir:

• Örneğin proje1-staging.domain.com veya clientx-test.domain.com gibi adlarla sahiplik ve amacı kaydedin.
• Disk/veri saklama süresini izleyin; yalnız artık gerekmeyen staging verisini, ortak bağımlılıkları doğruladıktan sonra temizleyin.
• MultiPHP gibi araçlarda sürümün gerçek domain/handler kapsamını ve kalıtılan ayarları kontrol edin; test değişikliğinin canlı siteyi etkilemediğini doğrulayın.

Kaynak yoğun testler için VPS veya dedicated çözümler

Yük testi ve büyük migrasyon provaları için kapasitesi planlanmış ayrı test ortamı gerekebilir. VPS veya fiziksel sunucu etiketi tek başına bağımsızlık sağlamaz; ortak ağ, depolama, DB ve hesap sınırlarını doğrulayın. Sağlayıcının izin verdiği test kapsamını kullanın; canlı hizmete veya üçüncü taraflara ölçüsüz yük yöneltmeyin.

Güvenlik önlemlerini staging’in ihtiyaçlarına uyarlayın

Test ortamının erişim ve güncelleme sorumluluğu devam eder. Canlı ortam için kullandığınız güvenlik ilkelerini staging’in ayrı sırları, test verileri ve servis bağlantılarına göre uyarlayın:

• Güçlü parola politikaları
• İki faktörlü kimlik doğrulama (2FA)
• Güncel WordPress çekirdeği, tema ve eklentiler
• Güvenlik eklentisi veya WAF kuralları

Bu kontrolleri staging’de doğrulayın; canlı kimlik bilgilerini veya e-posta/ödeme ayarlarını aynen kopyalamayın. Kurulu bir güvenlik eklentisi tek başına ortam ayrımını sağlamaz.

Kurulumu ve Dağıtımı Doğrulayarak Tamamlayın

Tek site WordPress için staging; ayrı DB ve dosyalar, kontrollü erişim, test servisleri ve tutarlı dağıtım planı birlikte hazırlandığında yararlı olur. Alt alan adı açmak veya dosya kopyalamak bu koşulları kendiliğinden sağlamaz.

Özetlemek gerekirse yol haritanız kabaca şöyle olabilir:

• Güncel Domains akışında ayrı kökü, yetkili DNS’yi ve hostname’i kapsayan TLS’yi doğrulayın.
• Önce erişimi ve otomatik işleri denetim altına alın; sonra tutarlı, geri yüklenebilir kopyayı oluşturun.
• Ayrı DB/kullanıcı, URL’ler, sırlar, cache ve test entegrasyonlarını WordPress çalışmadan hazırlayın.
• Yetkisiz erişimi, noindex çıktısını ve gerçek mail/ödeme/webhook gönderiminin olmadığını test edin.
• Aynı test edilmiş değişiklikleri canlı veriyi koruyan planla dağıtın; açılıştan önce ve sonra doğrulayın.

Hosting seçerken panel lisansı, DB/disk limitleri, yedek geri yükleme yetkisi ve yönetim sorumluluğunu netleştirin. Özel migrasyon veya uygulama geliştirme desteğinin seçilen pakete dahil olduğunu varsaymayın.

Canlıdan staging’e her yenileme, test ortamının sırlarını, erişim korumasını, cron ve dış servis ayarlarını yeniden kontrol etmeyi gerektirir. Kullanılmayan kopyayı kaldırmadan özgün çalışmayı yedekleyin; yalnız staging’e ait dosya, DB, kullanıcı, DNS ve işleri silin, ortak bağımlılıkları koruyun.