PHP 8 projelerinde canlıya geçiş için uygulamalı kontrol listesi
Bir PHP sürüm geçişini yalnızca sitenin ana sayfasını açarak doğrulamak kolaydır; fakat ödeme bildirimi, zamanlanmış görev veya dosya yükleme akışı birkaç saat sonra hata verebilir. Bu rehber, bir web uygulamasını yeni PHP sürümüne geçirirken kontrol edilebilecek noktaları tek yerde topluyor. Belirli bir hosting paketi veya ücretli hizmet teklifi değildir.
1. Önce çalışan ortamın envanterini çıkarın
Web isteklerinin kullandığı PHP sürümüyle cron/CLI sürümünü ayrı ayrı kaydedin. PHP uzantılarını, memory_limit değerini, dosya yükleme sınırlarını, saat dilimini ve uygulamanın Composer gereksinimlerini not edin. Şifreli bir eklenti kullanılıyorsa PHP sürümü kadar uygun ionCube Loader ve satıcının sürüm desteği de önemlidir.
2. Hedef sürümün geçiş notlarını okuyun
Küçük sürüm numarası değişmesi, hiçbir uyumsuzluk olmayacağı anlamına gelmez. Örneğin PHP 8.3 → 8.4 geçişi için resmi kılavuz; geriye dönük uyumsuzlukları, kullanımdan kaldırılan özellikleri ve kaldırılan uzantıları ayrı başlıklarda toplar. Kullandığınız hedef sürümün kendi kılavuzunu inceleyin:
PHP resmi geçiş kılavuzu — 8.3 → 8.4 örneği 3. Test ortamını gerçek senaryolarla sınayın
Sadece giriş ekranını denemek yerine aşağıdaki gibi bir kabul listesi oluşturun:
- Üyelik açma, giriş, parola sıfırlama ve oturum sonlandırma
- Boş alan, Türkçe karakter ve uzun metin içeren form gönderimleri
- İzin verilen ve reddedilmesi gereken dosya yüklemeleri
- Başarılı/başarısız ödeme, iptal ve tekrarlanan callback bildirimi
- Cron, e-posta kuyruğu, SMS ve dış API zaman aşımı
- Yetkili kullanıcı ile normal kullanıcının erişim sınırları
Test ortamında gerçek müşterilere SMS/e-posta göndermemek ve ödeme almamak için sağlayıcının test ortamını veya kontrollü sahte verileri kullanın. Üretim verisini kopyalıyorsanız kişisel bilgileri maskeleyin.
4. Logları görünür, sırları kapalı tutun
Hataları son kullanıcıya ayrıntılı olarak göstermek yerine sunucu loguna yönlendirin. Log kayıtlarında zaman, istek kimliği, işlem türü ve hata kategorisi bulunsun; parola, API anahtarı, kart bilgisi ve oturum çerezi bulunmasın. Böylece aynı işlemin uygulama, kuyruk ve dış servis tarafındaki izini karşılaştırabilirsiniz.
5. Yedek ile geri dönüş planını ayrı düşünün
Yedek dosyasının varlığı tek başına geri dönülebileceğini göstermez. Geri yüklemeyi test edin; veritabanı şemasındaki değişikliklerin eski kodla uyumunu değerlendirin. Geçiş sırasında yeni sipariş/veri oluşursa eski veritabanını geri yüklemek bu kayıtları kaybettirebilir. Geri dönüş koşulunu, veri mutabakatını ve karar verecek kişiyi önceden belirleyin.
6. Yayından sonra aynı kontrolleri tekrar çalıştırın
CLI ile web sürecinin aynı hedef sürümde olduğunu, cron görevlerinin tamamlandığını ve callback adreslerinin doğru ortama gittiğini doğrulayın. Hata oranı, yanıt süresi ve kuyruk birikimini geçiş öncesi ölçümlerle karşılaştırın. Her uygulama için tek bir performans artış yüzdesi beklemek yerine kendi senaryonuzu ölçün.
Kopyalanabilir geçiş kaydı
Uygulama / mevcut sürüm / hedef sürüm / uzantılar / test sonucu / yedek geri yükleme sonucu / geri dönüş koşulu / sorumlu kişi.
Hazırlayan: AIOR Teknoloji. İlgili temel kavramları
AIOR Bilgi Bankası’ndaki PHP 8 rehberinde de ele alıyoruz. Burada PHP sürüm geçişinde karşılaştığınız somut hata ve çözüm örneklerini paylaşabilirsiniz; gizli bilgiler içeren logları yayımlamayın.