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ı.
Açık konuşayım. PHP’nın son birkaç yılda aldığı yol beni gerçekten şaşırtıyor. 2018-2019 civarında “PHP öldü zaten” diyenler vardı etrafımda — hatırlıyorum, bir konferansta biri bunu yüzüme karşı söylemişti. Ben hiç katılmadım. Çünkü sahada, özellikle e-ticaret ve içerik yönetim sistemlerinde PHP hâlâ devasa bir paya sahip; WordPress tek başına internetin %40’ından fazlasını çalıştırıyor ve bu rakam küçümsenecek bir şey değil. Yanı PHP’yi görmezden gelmek… pek akıllıca değil.
PHP 8.5 ile Gelen Yenilikler: Kağıt Üstü mü, Sahada mı?
Şöyle söyleyeyim, PHP 8.5’in en çok konuşulan özelliği pipe operatör (|>). Bunu ilk duyduğumda “sonunda!” dedim. Neyse, gerçekten. Fonksiyonel programlama yapanlar bilir — F# ve Elixir’de bu operatör yıllardır var, PHP dünyasında işe iç içe fonksiyon çağrıları bazen öyle bir hâl alıyordu ki, iki gün sonra kendi yazdığın kodu okuyamıyordun.
İnanın, Şöyle düşünün — eskiden böyle yazıyordunuz:
$result = array_map('strtoupper', array_filter($items, function($item) {
return strlen($item) > 3;
}));PHP 8.5 ile aynı şeyi çok daha okunabilir hâle getirebiliyorsunuz. Tabi pipe operatör’ün asıl gücü daha karmaşık zincirleme işlemlerde ortaya çıkıyor. Ama şunu söyleyeyim — henüz her framework bu söz dizimine tam uyum sağlamadı. Laravel ve Symfony çevrelerinin bunu benimsemesi biraz zaman alacak. Kağıt üstünde süper. Pratikte? Göreceğiz artık.
Fatal Error Backtrace: İşte Bu Lazımdı
Bir de fatal error’larda artık backtrace geliyor. Dur bir saniye, şunu vurgulayayım — bu özellik gerçekten hayat kurtarıcı. 2024 sonunda Logosoft’ta bir e-ticaret müşterimizin prodüksiyon ortamında rastgele memory limit hatası alıyorduk; fatal error veriyor ama nerede, hangi çağrı zincirinde olduğunu bulmak için saatlerce log karıştırdık, Xdebug açmak prodüksiyonda performansı çökertiyor, New Relic entegrasyonu da o projede yoktu. Saatlerce. Boşa.
PHP 8.5’teki backtrace özelliği tam da bu senaryolar için biçilmiş kaftan. Fatal error olduğunda artık hangi dosya, hangi satır, hangi fonksiyon zinciri — hepsini görüyorsunuz. Basit ama etkili.
Performans ve Tip Güvenliği İyileştirmeleri
Şunu söyleyeyim, PHP 8.5 performans tarafında da iyileştirmeler getiriyor. Tip güvenliği konusunda daha sıkı kurallar var — bu konuda %100 emin değilim ama sanırım enum’lar üzerinde de bazı geliştirmeler mevcut, resmî release sayfasını incelemenizi tavsiye ederim detaylar için.
Bence, Benim gözlemlediğim kadarıyla, PHP 8.0’dan 8.5’e kadar her minör versiyon ortalama %3-7 arası performans artışı sağladı. Tek başına devasa bir fark değil. Ama kümülatif olarak bakınca? Fena değil. Hatta baya iyi.
Azure App Service’te PHP 8.5 Nasıl Kurulur?
Bak şimdi, Bak şimdi, üç farklı yöntem var ve hangisini seçeceğiniz tamamen sizin iş akışınıza bağlı. Ben her birini farklı senaryolarda kullanıyorum.
1. Azure Portal Üzerinden (En Kolay Yol)
Portal üzerinden yeni bir Web App oluştururken Runtime stack olarak PHP 8.5 seçebiliyorsunuz. Mevcut bir uygulamanız varsa, Configuration > General Settings altından PHP versiyonunu değiştirebilirsiniz. Bu kadar. Gerçekten bu kadar basit.
Ama — dikkat edin — versiyon değiştirdiğinizde uygulama yeniden başlıyor. Prodüksiyon ortamında bunu mesai saatleri dışında yapın. Geçen ay bir müşterimiz bunu tam öğle arası yaptı, 2 dakikalık kesinti öldü. Müdür aradı tabi… değişti konusundaki yazımız yazımızda bu konuya da değinmiştik.
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). GitHub Actions’ta 50 Yeniden Çalıştırma Sınırı: Sahada Ne Değişiyor? yazımda Actions" data-glossary-term="GitHub Actions">GitHub Actions ile deployment otomasyonundan bahsetmiştim — oradaki prensiplerin büyük çoğunluğu burada da geçerli. Daha fazla bilgi için Azure MCP Server 2.0: Kendi Sunucunuzda Ajan Otomasyonu yazımıza bakabilirsiniz.
Hangi Senaryo İçin Ne Yapmalı?
Şöyle ki, Herkesin durumu farklı. Küçük bir startup ile büyük bir banka arasında dağlar kadar fark var. Şöyle bir tablo hazırladım:
| Senaryo | Önerilen Yöntem | Geçiş Süresi | Risk Seviyesi |
|---|---|---|---|
| Kişisel blog / WordPress | Portal üzerinden tıkla-geç | 5 dakika | Düşük |
| Orta ölçekli e-ticaret | Staging slot + CLI | 1-2 saat | Orta |
| Enterprise / Bankacılık | Bicep + CI/CD pipeline | 1-2 hafta (test dahil) | Yüksek |
| Legacy PHP 7.x uygulaması | Önce 8.3’e, sonra 8.5’e | Haftalar/Aylar | Çok Yüksek |
En son satıra dikkat edin. PHP 7.x’ten direkt 8.5’e atlamak… cesur bir hareket olur. Ama aptalca. 2023’te bir müşterimiz bunu denedi — tam bir felaket (bizzat test ettim). Deprecation uyarıları, kırılan eklentiler, değişen davranışlar, her yer kırmızı. Adım adım çıkmak lazım. Mutlaka. Daha fazla bilgi için Copilot Cloud Agent Metriği: Kullanımı Ölçmek Kolaylaştı yazımıza bakabilirsiniz.
Geçiş Öncesi Kontrol Listesi
İşin aslı şu ki, PHP versiyon güncellemesi sadece “tıkla ve geç” meselesi değil — özellikle prodüksiyon ortamlarında. Yılların verdiği tecrübeyle şu listeyi oluşturdum:
- Composer bağımlılıklarını kontrol edin:
composer why-not php 8.5komutu ile hangi paketlerin uyumsuz olduğunu görün. Bazen bir tane küçük, kimsenin adını bile bilmediği paket her şeyi bloke ediyor. - Deprecation uyarılarını temizleyin: PHP 8.4’te deprecated olan özellikler 8.5’te kaldırılmış olabilir. PHPStan veya Psalm ile statik analiz çalıştırın.
- Extension uyumluluğunu doğrulayın: En çok da pecl extension’ları bazen yeni PHP versiyonlarında derlenmeyebiliyor.
- Yük testi yapın: Performans iyileşmesi bekliyorsunuz ama garanti yok. Kendi uygulamanızla test edin, başkasının benchmark’ına güvenmeyin.
- Rollback planı hazırlayın: Bir şey ters giderse 30 saniyede eski versiyona dönebilmek lazım. Deployment slot’lar burada altın değerinde. — bunu es geçmeyin
PHP versiyon güncellemesi bir sprint değil, maratondur. Acele eden kaybeder — bunu en az üç projede acı şekilde öğrendim.
Azure App Service’te PHP: Avantajlar ve Sınırlamalar
Neden Azure App Service? Neden bir VM’de veya container’da çalıştırmıyoruz? Güzel soru. Gerçekten.
İşte, i̇lginç olan şu ki, App Service’in en büyük avantajı yönetim yükünü minimuma indirmesi — OS güncellemeleri, güvenlik yamaları, ölçeklendirme, Microsoft hallediyor, sız sadece kodunuza odaklanıyorsunuz. Küçük ve orta ölçekli projeler için bu müthiş bir rahatlık, lafı gevelemeden söyleyeyim.
Gel gelelim sınırlamalar da var. Mesela özel PHP extension’ları yüklemek istiyorsanız işler biraz karmaşıklaşıyor, custom container kullanmanız gerekebiliyor. Bir de App Service’in Linux versiyonunda dosya sistemi performansı bazen (ciddiyim). hmm, nasıl desem… beklentilerin altında kalabiliyor. Bilhassa de çok fazla dosya okuma/yazma yapan uygulamalarda ciddi sorun. WordPress’in wp-content klasöründe binlerce dosya varsa ve cache mekanizmanız dosya tabanlıysa, Redis’e geçmeyi düşünün. Ciddi ciddi. Daha fazla bilgi için Copilot Güvenlik Taramasında: Riski Okutan Yeni Hamle yazımıza bakabilirsiniz.
Bir de maliyet meselesi var. App Service’in B1 planı ayda yaklaşık 13 dolar, P1v3 işe 100 dolar civarı. Küçük bir WordPress sitesi için B1 yeterli, ama ciddi trafik alan bir e-ticaret sitesi için en az P1v3, hatta P2v3 lazım. Azure SDK’da Node.js 20 Desteği Bitiyor: Hazır mısınız? yazımda runtime güncellemeleriyle ilgili benzer değerlendirmeler yapmıştım, o perspektif burada da geçerli.
Sahadan Bir Geçiş Hikâyesi
Şubat 2026’da Logosoft’ta bir müşterimiz — orta ölçekli bir lojistik firması — PHP 8.2’den 8.4’e geçiş yaptı. Ben bu projeye danışman olarak dahil oldum. Süreç tam 3 hafta sürdü. GitHub Copilot Pro Denemeleri Neden Durdu? yazımızda bu konuya da değinmiştik.
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
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
3 comments