Geliştirmeden Canlıya Kontrollü Geçiş
Küçük bir tema güncellemesi veya migration, canlı istekleri beklenmedik biçimde etkileyebilir. Değişikliğin kısa olması düşük risk garantisi değildir. Sıfır kesinti dağıtım hedefi; aynı sürümü test etmek, kalıcı veriyi korumak ve başarısızlık durumunu önceden planlamakla değerlendirilmelidir.
Bu rehber WordPress ve Laravel için geliştirme, staging ve canlı ortam akışını ele alır. Kod ve yapılandırma ayrımı, staging verisi, medya, atomik kod geçişi, veritabanı uyumluluğu, cache ve işçi süreçleri aynı planın parçalarıdır. Örnekler uygulanabilir ilkeleri gösterir; gerçek müşteri sonucu veya kesintisizlik garantisi değildir.
Önce her ortamın görevini ve veri sınırını belirleyin. Ardından hazırlama, aday sürüm kontrolü, aktivasyon ve geri dönüş adımlarını aynı tanımlı akışta birleştirin. İşe yarayan ölçüt, yalnız dağıtım komutunun tamamlanması değil kritik kullanıcı işlemlerinin doğru devam etmesidir.
Geliştirme, Staging ve Canlı Ortamların Görevleri
Geliştirme ortamı hızlı değişiklik ve otomatik test içindir. Staging, aday sürümü canlıya benzer altyapıda prova eder. Canlı ortam gerçek kullanıcı ve kalıcı iş verisini taşır. Bu ortamların veritabanı, kuyruk, cache, dosya alanı ve dış servis kimlik bilgileri birbirinden ayrılmalıdır.
PHP/uzantılar, veritabanı sürümü, cache davranışı, proxy/TLS ve işçi ayarlarını canlıya benzetin. Ancak benzer altyapı aynı veri hacmi ve trafik anlamına gelmez; farkları kaydedin. Performans testleri gerçekçi dağılım ve büyüklükte sentetik veya uygun biçimde anonimleştirilmiş veri kullanmalıdır.
Feature ve staging branch’leri kullanılabilir, fakat tek zorunlu Git modeli değildir. Esas olan staging’de geçen aynı commit ve tanımlı build çıktısını canlıya taşımaktır. Sonradan yeniden derleme veya farklı birleştirme sonucu oluşursa değişen çıktıyı tekrar doğrulayın. Küçük değişikliklerin incelenmesi kolay olabilir; veri dönüşümü içeren tek satır yine yüksek etkili olabilir.
WordPress Cephesinde Yolculuk: Tema, Eklenti, Veri ve Medya
Versiyonlanmayan şey, kontrolden çıkar
Özel tema, child theme ve proje eklentilerini sürüm kontrolüne alın; bağımlılık sürümlerini ve build çıktısını kaydedin. Composer/Bedrock gibi düzenler kullanılabilir, ancak paket sürümünü kilitlemek bütün ortamları aynı yapmaz. Canlı panelden yapılan tema/eklenti değişiklikleri ve otomatik güncellemeler dağıtım manifestiyle uzlaştırılmalıdır; denetlenmeyen kod farklılığı bırakmayın.
Staging’de giriş, yönetim, formlar ve mağaza varsa kupon/ödeme akışlarını test edin. Eklenti güncellemesi yalnız dosya değiştirmeyebilir; veritabanı yükseltme işleri ve arka plan görevleri de başlatabilir. Eski eklenti dosyalarına dönmenin yeni şemayla çalışıp çalışmadığını ayrıca doğrulayın.
Veritabanı değişiklikleri ve o meşhur alan değiştirme
Canlıdan staging’e kopyalanan veride URL değişimi gerekiyorsa WP-CLI ile seri hale getirilmiş veriyi anlayan search-replace kullanın. Hedef kurulum, tablolar ve sütunları açık seçin; önce –dry-run çıktısını inceleyin, rutin URL taşımada guid alanını koruyun. Staging URL değişimini canlı dağıtımda tekrarlamayın. Canlıda gerçekten adres değişecekse ayrı yedek, üretime özel değerler ve doğrulanmış kapsam gerekir. Günlüklerde kişisel veri veya sır yayımlamayın.
Staging Medyasını Canlı Yazmalardan Ayırın
Nesne depolama medya kopyalama ihtiyacını azaltabilir; tek başına CDN veya yedek değildir. Staging, yalnız gerekli herkese açık canlı medyayı salt okunur kullanabilir. Test yükleme/silme işlemlerini ayrı bucket veya prefix’e yöneltin; canlı dosyaya yazma yetkisi vermeyin. Özel medyayı ayrıca ayırın veya anonimleştirin. WordPress medyasını S3 uyumlu depolamaya taşıma rehberi CDN ve erişim seçeneklerini açıklar.
Önbellek ile anlaş, seni sırtında taşır
Sayfa cache’i uygun yanıtlarda kaynak işini azaltabilir. Dağıtımda kaynak ve CDN HTML’ini bağımlılıklarına göre geçersiz kılın; doğru sürüm URL’sine işaret eden CSS/JS dosyalarını ve eski HTML’in kullandığı önceki dosyaları koruyun. Yalnız kişisiz, yan etkisiz sayfaları ısıtın. WordPress ve WooCommerce tam sayfa cache rehberi özel oturum istisnalarını tamamlar.
Laravel Cephesinde Yolculuk
Atomik dağıtımın huzuru
Yeni Laravel kodunu ayrı releases dizininde hazırlayın; current canlı sürümü göstersin. Paylaşılan kalıcı veriyi bağladıktan sonra bağımlılıkları ve sürüme özel cache’i hazırlayın. Aynı dizindeki geçici sembolik bağı rename/GNU mv -T ile current üzerine değiştirmek bağın kaybolduğu boşluğu önleyebilir; ln -nfs buna eşdeğer garanti vermez. İşlem uygulama, veritabanı ve bütün istekler için tek atomik işlem değildir.
VPS üzerinde dizin ve süreç ayrıntıları için Laravel dağıtım rehberini kullanın. Dağıtım, rollback ve temizlik aynı kilidi paylaşmalı; eski istekler ve işçiler bitmeden kullanılan release dizinleri silinmemelidir.
Önbellekleri ısıt, işçilere nazik davran
Önce adayın ortamını ve storage/log bağlantılarını hazırlayın; Composer betikleri uygulamayı açabilecekse ortam onlardan önce hazır olmalıdır. bootstrap/cache sürüme özel kalsın. Tüm storage paylaşıldığında varsayılan storage/framework/views de paylaşılır ve view:cache önce onu temizleyebilir. config/view.php içindeki compiled değerini örneğin base_path(‘bootstrap/cache/views’) olarak sürüme özel yola ayarlayıp dizini oluşturun; ardından config/route/view cache’lerini üretin. Horizon yalnız Redis kuyruklarını yönetir; devam ettirmek yeni kodu yüklemez. Süreç yöneticisiyle durdurup işlerin bitmesini bekleyin, geçişten sonra yeni current yolundan başlatın.
Resmî kaynaklara bir göz at
Laravel dağıtım belgesinde kurulu sürümü seçin. config:cache sonrasında normal .env yüklemesi yapılmaz; env() yalnız yapılandırma dosyalarında kullanılmalıdır. Cache oluşturulurken üretim sırlarının doğru olması ve cache dosyasının erişim izinleri önemlidir. Geniş cache temizleme komutlarını ortak oturum/veri cache’inde gelişigüzel kullanmayın.
Hazırlık ve Sağlık Kontrolü Sınırları
Bir dağıtımı iki kez yaşa: önce sakince, sonra gerçek
Hazırlık sırasında hedef ortamı bağlayın, temiz bağımlılık/build çıktısını kurun ve uygulamanın sürüme özel cache’lerini oluşturun. Sağlık kontrolünü hâlâ eski current sürümünü sunan genel URL’ye değil adayın gerçek yoluna bağlı özel vhost veya test hizmetine gönderin. Uygulama açılışı, gerekli bağımlılıklar ve yan etkisiz kritik istekler kontrol edilmelidir. Laravel’in varsayılan /up yanıtı bütün veri ve kuyruk akışlarını doğrulamaz.
VPS CI/CD rehberi rsync, sembolik sürümler ve systemd adımlarını ayrıntılandırır. Aynı artifact’i terfi ettirin, SSH sunucu anahtarını doğrulayın ve adım hatalarını saklamayın. Aday kontrolü başarısızsa aktivasyon yapılmamalı; daha önce migration çalıştıysa bunun canlı şemayı etkilemiş olabileceği kaydedilmelidir.
Blue/Green’i karmaşıklaştırmadan düşün
Blue/green, iki çalışan ortam arasında trafiği değiştirmektir; release klasörünün bağını çevirmekle aynı değildir. İki ortam çalışsa da ortak veritabanı ve kuyruk uyumluluğu ortadan kalkmaz. Trafik değişiminde eski bağlantıları boşaltma, sağlık ve kaynak kapasitesini planlayın. Daha basit release yöntemi seçilebilir, fakat sağladığı yalıtımı abartmayın.
Veritabanı Değişiklikleri: Korkulan Anı Sakinleştirmek
Önce şema, sonra kod; bazen de önce kod, sonra şema
Şema ve kod sırası değişikliğe bağlıdır; her adımda o anda çalışan kod desteklenen şemayla çalışmalıdır. Genişlet-daralt yaklaşımında uyumlu eklemeler, yeni kod, sınırlı partilerle veri doldurma ve en son kısıtlama/silme yer alır. Sütun eklemek bile kullanılan veritabanı sürümünde kilit maliyeti yaratabilir. Bayrak kapalıyken yeni kodun henüz olmayan alanlara erişmediğini doğrulayın; eski işçiler ve rollback ihtiyacı bitmeden eski yapıyı kaldırmayın.
Büyük tabloda DDL davranışını gerçek veritabanı motoru/sürümüyle test edin. Nullable alan, varsayılan değer veya “online” araç her durumda kilitsizlik sağlamaz. Backfill işlemlerini sınırlayın; ilerleme, hata sonrası devam ve veri doğrulamasını planlayın. NOT NULL öncesinde mevcut NULL’lar doldurulmalı ve eski yazıcılar artık NULL üretmemelidir. Laravel migrate –force yalnız onay istemini atlar.
Yedek, geri dönüş ve günlükler
Veritabanına uygun tutarlı yedek ve ölçülmüş geri yükleme yolu gerekir; çalışan veri dosyalarını sıradan dosya kopyasıyla almak yeterli değildir. Eski yedeğe dönmek sonradan gelen sipariş ve yazmaları kaybettirebilir. Restic ve Borg yedekleme rehberi dosya saklama seçeneklerini tamamlar. Kod rollback’i, veritabanı kurtarma ve dış sistemlerdeki etkileri uzlaştırma ayrı işlemlerdir.
Önbellek, CDN ve Oturumlar: Sessiz Değişiklik Yapmanın İncelikleri
Önbelleği kırmadan tazelemek
HTML yeni asset URL’lerine işaret etmeli, eski URL’ler cache’li HTML veya açık tarayıcılar kullanırken erişilebilir kalmalıdır. CDN purge tarayıcı cache’ini silmez. Önce kaynak HTML cache’ini, sonra ilgili CDN bağımlılıklarını geçersiz kılın; yalnız CSS dosyasını temizlemek eski HTML başvurusunu düzeltmeyebilir. Isıtma, gerçekten paylaşılabilir sayfaların cache’ini kontrollü biçimde doldurmalıdır.
WordPress’te tema değişimi anasayfa, arşiv, ürün ve dil varyantlarını etkileyebilir; purge kapsamı bu bağımlılıklara göre belirlenir. Laravel derlenmiş view cache’i ise aday sürümün hazırlık adımıdır, aktivasyon sonrası ortak sayfa cache’i ısıtmayla karıştırılmamalıdır. Her iki katmanda kişisel yanıtları ortak saklamadan ayırın.
Oturumlar ve işçiler
Oturum deposu bütün ilgili sürümlere ve sunuculara erişilebilir olmalı; anahtarlar, cookie kapsamı ve veri biçimi uyumlu kalmalıdır. Tek sunucuda doğru paylaşılan dosya oturumları çalışabilir; Redis zorunlu değildir ve cache eklentisi oturumları otomatik taşımaz. Horizon veya CLI işçisini yalnız duraklatıp devam ettirmek yerine gerektiğinde yeni koddan yeniden başlatın. Süreç yöneticisinin geçiş öncesi eski current üzerinde otomatik açılmasını önlemek için yönetici üzerinden stop/bekle/start koordine edin.
Staging Verisi: Gerçekçi, Güncel ve Güvenli
Maskeleyerek tazele
Önce sentetik veri kullanmayı değerlendirin. Canlı veri gerekiyorsa erişimi sınırlı hazırlık alanında, staging kullanıcıları görmeden önce kişisel veriyi kaldırın veya uygun anonimleştirme uygulayın; ilişki ve dağılımları test amacı için koruyun. Yalnız e-posta alanını değiştirmek bütün veriyi anonim yapmaz. E-posta/SMS’i test alıcılarına, ödemeyi sandbox’a yöneltin; webhook, cron, kuyruk ve dış API bağlantılarını da ayırın. Canlı sırları ve ödeme verisini kopyalamayın.
Ortak Okuma ile Yazma Yetkisini Ayırın
Staging’in canlı medyaya erişmesi gerekiyorsa yalnız gerekli herkese açık dosyaları salt okunur sunun. Test yükleme ve silmeleri ayrı alanda tutun; özel içerik için ayrı veya anonimleştirilmiş kopya kullanın. İmzalı URL yalnız tanımlı erişim süresi/kapsamı sağlar; staging’in canlı depoya yazma yetkisini kaldırmanın yerine geçmez. CDN ve nesne deposunda ortam sınırlarını ayrıca doğrulayın.
Güvenli Dağıtımda Küçük Ama Etkili Dokunuşlar
Sağlık uç noktaları ve ısıtma turu
Adaya bağlı sağlık kontrolünden sonra yalnız yan etkisiz ve ortak cache’e uygun sayfaları ısıtın. Giriş, sepet ve ödemeyi ayrı oturumlar ve ödeme test sistemiyle sınayın; bu kişisel yanıtları ortak cache’e doldurmayın. Isıtma kapasite veya hatasız hizmet garantisi değildir. Geçiş sonrasında canlı URL’den sürüm kimliği, yanıt gövdesi ve kritik iş akışını tekrar doğrulayın.
Özellik bayrakları ile yumuşak açılış
Özellik bayrağı, kodu kontrollü kullanıcı grubuna açmaya yardımcı olur; veritabanı değişimini veya daha önce oluşan yan etkiyi geri almaz. Bayrak durumları farklı HTML üretiyorsa cache varyantlarını doğru ayırın. Gizli kodun prod’a çıkması çalıştığının kanıtı değildir; test trafiği ve ölçüm gereklidir.
CI/CD Akışında Tam Sıra
Ritmi yakaladığında, dağıtım sıradanlaşır
Test edilmiş artifact’i seçin ve dağıtım kilidini alın. Aday dizini, hedef ortamı, paylaşılan veriyi ve izinleri hazırlayın; bağımlılıkları ve sürüme özel cache’i üretin. Gerekli uyumlu şema geçişini kontrollü çalıştırıp aday sağlığını doğrulayın. İlgili işçileri durdurun, aktif işlerin bitişini ve duruş sonucunu kontrol edin; kod/traffic geçişini yapın ve süreçleri yeni sürümden başlatın. Kaynak/CDN cache’ini bağımlılıklarına göre yenileyip güvenli sayfaları ısıtın. Canlı sağlık/iş sonuçlarını doğrulayın; hatada mevcut şema/veriye uygun rollback veya ileri düzeltme kararı verin. Eski sürümü ancak kullanım ve saklama koşulları bitince temizleyin.
Artifact, container veya rsync farklı taşıma seçenekleridir; hiçbiri kendi başına geri dönüş garantisi vermez. Commit/build kimliği, artifact özeti, ortam sürümü ve her adımın sonucu kaydedilmelidir. CI çıktısına üretim sırrı veya staging config cache’i koymayın. Tekrar çalıştırıldığında hangi adımların güvenli olduğu açık olmalıdır.
WordPress ve Laravel için ortak nokta
WordPress’te kod yanında eklenti yükseltme işleri, medya ve cron planı önemlidir; staging veritabanını canlıya bütünüyle kopyalamak yayın yöntemi değildir. Laravel’de config/view cache ve uzun ömürlü süreçler ayrıca geçiş ister. Ortak hedef, kullanıcı verisi ve iş sonuçlarını koruyarak test edilmiş sürümü kontrollü etkinleştirmektir.
İstenen kurulumun püf noktalarını uçtan uca görmek istersen, VPS üzerinde sıfır kesinti CI/CD kurma rehberi ve Laravel dağıtım yol haritası iyi birer referans olur.
Altyapı ve Ağ: Küçük Eşikler Büyük Akışlar Yaratır
Web sunucusu ayarları ve ılık başlatma
Nginx ve FPM yapılandırması, izinler ve gerçek sürüm yolları geçişte önemlidir. Nginx yalnız bağ değişimi için reload istemeyebilir; FPM/OPcache davranışı kurulumla doğrulanmalıdır. Uzun bağlantılar, eski işçiler ve preload gibi durumlarda reload komutunun dönmesi yeni kodun kullanıldığını kanıtlamaz. Geçici eski/yeni süreç örtüşmesi için kaynak payı bırakın.
CDN ve kenar katmanında netlik
CDN tazeliğini, cache key varyantlarını ve purge kapsamını değişen içeriğe göre seçin. Küçük bir asset değişimi seçici yenileme gerektirebilir; global şablon veya yanlış kişisel cache politikası daha geniş temizlik isteyebilir. HTTP/2 ya da HTTP/3 seçimi cache doğruluğunu kendi başına sağlamaz. Yeni içerik ve kodlama/oturum varyantlarını gerçek yanıtlarla kontrol edin.
Geçişi Kanıtla Tamamlayın
Geliştirme ve staging, canlı veriden ayrı olmalı; canlıya aynı doğrulanmış build taşınmalıdır. WordPress eklenti/medya/cache davranışı ve Laravel şema/cache/işçi geçişi birlikte planlandığında sorunlar daha erken görülebilir. Atomik bağ yalnız dosya yolu geçişini korur; kalan doğruluk koşulları sağlık ve iş akışı kontrolleriyle gösterilmelidir.
Kabul ölçütlerini gecikme, hata, sipariş/iş sonucu ve veri doğruluğuyla tanımlayın. Staging’de başarısız aday, migration sorunu ve aktivasyon sonrası geri dönüşü de prova edin. Cache ısıtma ile kişisel akış testlerini ayırın; yedeklerin geri yüklenebildiğini ve eski asset’lerin erişilebilir kaldığını doğrulayın. İzleme süresini keyfî birkaç dakika yerine risk ve iş döngüsüne göre seçin.
Ayrıntılar için tam sayfa cache rehberi, WordPress medya depolama rehberi ve VPS CI/CD rehberi kullanılabilir. Seçilen kuralları ve test sonuçlarını sürüm kaydıyla birlikte saklayın; altyapı değiştikçe yeniden doğrulayın.
