PHP 8.5 Azure App Service’te: Ne Değişti?
Bak şimdi, Geçen hafta bir müşterimizin PHP uygulamasını Azure App Service’te güncellerken tam da şu haberi gördüm: PHP 8.5 artık neredeyse tüm Azure bölgelerinde kullanıma açılmış. Hani bazen zamanlama o kadar güzel denk gelir ya — işte tam öyle bir andı.
📋 İçindekiler
-
2. Azure CLI ile Otomasyon
Bak şimdi, CLI kullanmayı tercih edenler için işlem oldukça düz: (bizzat test ettim)
# Yeni PHP 8.5 web app oluşturma az webapp create \ --resource-group myResourceGroup \ --plan myAppServicePlan \ --name myPhpApp \ --runtime "PHP:8.5" # Mevcut uygulamayı PHP 8.5'e güncelleme az webapp config set \ --resource-group myResourceGroup \ --name myPhpApp \ --linux-fx-version "PHP|8.5"CLI yöntemini özellikle birden fazla ortamı yöneten ekiplere öneriyorum. Dev, staging, production — hepsini tek bir script ile güncelleyebilirsiniz (yanlış duymadınız). Ha bu arada, güncellemeden önce mutlaka staging slot’ta test edin. Deployment slot kullanmıyorsanız… e, kullanmaya başlayın artık.
3. ARM/Bicep Template ile Infrastructure as Code
Enterprise seviyede çalışıyorsanız — ki Logosoft’taki müşterilerimizin çoğu öyle — Bicep template kullanmak en doğru yaklaşım. Şöyle bir snippet yeterli:
resource webApp 'Microsoft.Web/sites@2023-12-01' = { name: 'myPhpApp' location: resourceGroup().location properties: { siteConfig: { linuxFxVersion: 'PHP|8.5' } serverFarmId: appServicePlan.id } }İlginç olan şu ki, Bu yaklaşım özellikle CI/CD pipeline’larınız varsa çok değerli (evet, doğru duydunuz).
Neden mi bu kadar uzun? Çünkü kullandıkları bir ödeme entegrasyonu kütüphanesi PHP 8.4 ile uyumsuzdu. Kütüphanenin maintainer’ı güncelleme yapmamıştı, fork edip kendimiz düzeltmek zorunda kaldık. Zevkli değildi.
Sonuç? Geçiş sonrası sayfa yüklenme süreleri ortalama %12 düştü, bellek kullanımı %8 azaldı. Müşteri mutlu, biz mutlu. Ama o 3 haftalık süreçte yaşadığımız stres… neyse, uzatmayalım.
Dürüst olmak gerekirse, PHP 8.5’e geçişte de benzer sürprizler yaşanabilir. Hazırlıklı olun. Hele bir de third-party kütüphanelerinizi kontrol edin, Composer.lock dosyanızı dikkatlice inceleyin. Ve bir şey daha — acele etmeyin. Gerçekten etmeyin.
Sıkça Sorulan Sorular
Azure App Service’te PHP 8.5’e geçiş ücretsiz mi?
Evet, PHP runtime versiyonu değişikliği ek bir ücret gerektirmiyor. Zaten ödediğiniz App Service planı üzerinden çalışıyor. Sadece uygulamanız yeniden başlatılıyor, o kadar.
PHP 8.5’teki pipe operatör mevcut kodumuzu etkiler mi?
Tuhaf ama, Hayır, pipe operatör (
|>) yeni bir özellik olduğu için mevcut kodunuzu bozmaz (inanın bana). Kullanmak istiyorsanız yeni yazacağınız kodda kullanabilirsiniz, mevcut kodu değiştirmek zorunda değilsiniz.PHP 8.3 veya 8.4’ten 8.5’e direkt geçiş yapılabilir mi?
Genellikle evet. Minör versiyon atlama (8.3 → 8.5 gibi) genelde sorunsuz oluyor (buna dikkat edin). Ama yine de staging ortamında test etmenizi şiddetle tavsiye ediyorum. Deprecation uyarılarını dikkate alın ve composer bağımlılıklarınızı kontrol edin.
Windows’ta Azure App Service’te PHP 8.5 kullanabilir mıyım?
Şu an PHP 8.5 sadece Linux App Service’te mevcut. Windows App Service’te PHP desteği zaten bir süredir sınırlı ve Microsoft’un yönelimi Linux tarafına doğru. PHP için Linux planı tercih etmenizi öneririm.
WordPress sitemizi hemen PHP 8.5’e geçirmeli mıyız?
Acele etmeyin. WordPress core’un ve kullandığınız eklentilerin PHP 8.5 uyumluluğunu kontrol edin (kendi tecrübem). WordPress genellikle yeni PHP versiyonlarını hızlı destekliyor ama bazı eklentiler geride kalabiliyor. Bir-iki ay bekleyip ekosisteminin olgunlaşmasını görmek daha güvenli olabilir.
Kaynaklar ve İleri Okuma
Azure App Service’te PHP Web App Oluşturma — Microsoft Docs (ciddiyim)
Azure App Service İçin PHP Uygulaması Yapılandırma — Microsoft Docs
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.
Pınar H.
Pipe operator’ü bekliyordum açıkçası, Laravel projelerinde zincirleme işlemleri çok daha temiz yazacak. Fatal error backtrace meselesi ise küçük görünüyor ama production’da hata ayıklarken ne kadar zaman kurtardığını deneyimleyince anlıyorsunuz.
Serkan D.
Pipe operator gerçekten uzun süredir beklenen bir şeydi, iç içe fonksiyon çağrılarını okumak bazen işkenceye dönüyordu. Fatal error backtrace tarafı da çok işe yarayacak, özellikle production’da log okurken zaman kaybı ciddi oluyor. Bu arada CLI tarafındaki değişiklikleri merak edenler için de şu yazıya bakılabilir: https://www.askinkilic.com.tr/copilot-cli-metrikleri-artik-birlesik-ne-degisti/
Burcu Ç.
Pipe operator’ü merakla bekliyordum, özellikle iç içe fonksiyon çağrılarının karmaşıklaştığı yerlerde epey işe yarayacak gibi görünüyor. Fatal error backtrace de gerçekten eksikti, production’da bazen hatanın nereden geldiğini bulmak saatler alıyordu.
Yorumlar kapalı.








3 comments