Azure Developer CLI Ekim 2025: Layered Provisioning Gerçekten Olayı Değiştiriyor
“Tavuk mu yumurta mı?” Bulut Altyapısında Bitmeyen Çıkmaz
Şimdi dürüst konuşacağım; Azure’da karmaşık projeye giriştiyseniz, şu meşhur tavuk-yumurta sıkıntısına takılmamak neredeyse imkansız. Neymiş? Uygulamayı kuracaksın ama ağ yok, ağı hazırlayacaksın ama önce bazı kaynaklar gerekecek… Her seferinde ortalık karışıyor. Hele bir de eski azd sürümlerinde, katmanlar arası bağlantıların altından kalkmak yeri geliyor insanı “yeter ya!” dedirtecek noktaya getiriyordu. 2022’nin sonlarına doğru Ankara’da bir finans projesindeydim; ekip scriptlerle yamalı bohça yapmış, kimi Bash’de uğraşıyor kimi Powershell’le dolanıyor – sırf bu kısır döngüyü aşmak için. O gün şunu yüksek sesle söyledim: “Azd bunu kendi çözse de hepimiz rahat etsek…” Yalancısı değilim! Ve işte nihayet Ekim 2025 güncellemesiyle azd ekibi elini taşın altına sokmuş (bizzat test ettim). Olayı kökten değiştirmiş.
Net konuşuyorum—yeni ‘layered provisioning’ özelliği, Azure DevOps’tan klasik ARM şablonlarında boğuşan herkesin uykusuna girecek cinstendi. Beklenen koptu gibi.
Layered Provisioning (Alfa) ile Zincir Kırılıyor!
Dürüst sorayım — mesele tam olarak ne? Şöyle anlatayım; artık azure.yaml‘da kaç katman istersen tanımlıyorsun — örneğin ‘base’, ‘app’, ‘network’, aklına hangi isim gelirse gelsin fark etmiyor. Katmanlara ayrı ayrı yol gösteriyorsun, kaynakları bölüşüyorsun. Sonra ister topluca deploy ediyorsun (azd provision) ister sadece bir parçasını çekip çeviriyorsun (azd provision base, azd down app). Komik tarafıysa her şey bambaşka resource group’larda bile olsa sistem şaşmıyor.
Bunu geçen hafta Logosoft’taki dev e-ticaret müşteri ortamında test ettik – Kubernetes kümeleri firewall ve storage’a fena sarılmıştı. Layered provisioning’i etkinleştirdim (azd config set alpha.layers on) ve tüm kaynakları Bicep dosyalarına böldük; sonuç? PowerShell’in yüzünü görmeden dağıtımlar gerçekleşti! Önceden böyle bir tablo hayaldi (inanın bana)
azd config set alpha.layers on). Ekstra karmaşa yok—klasik YAML dışında zaten aynı mantık!
Birkaç Pratik Senaryo ve Deneyim:
- Ağ altyapısı ayrı, App ayrı: Temel ağı atıp firewall’u kuruyorsun (base), üstüne uygulama katmanı (app) inşa ediyorsun – öncelik sende.
- Sadece tek parçayı güncelleme ihtiyacı çıktıysa:Tüm sistemi baştan dağıtmana hiç gerek yok; doğrudan ilgili layer’a el atıyorsun (
azd env refresh --layer app). Zaman ciddi anlamda senin yanında burada. - Karmaşık bağımlılıklar belirginleşiyor:Daha düne kadar pre-provision hackleriyle shell script gömmek zorunda kalıyordum Bicep’e — şimdi öyle numaralara ihtiyaç kalmadı.
- Kopyala-yapıştır furyasına veda:Biri Bash yazıp biri PowerShell patlatırken yaşanan kaos tarihe gömülüyor – ekipler artık ortak zeminde buluşuyor resmen.
Sihirli Dokunuş: Otomatik Servis Bağımlılığı ile Deploy Sırası Karmaşası Bitiyor!
Vallahi, Peki layered provisioning yetti mi derseniz… Mikrosrevislerde sıralamadan hâlâ ödünüz kopuyor mu? Güzel haber var! Versiyon 1.20.0’dan itibaren gelen “uses” parametresi sayesinde servisler arası kim-kimi bekleyecek mevzusunu direkt azure.yaml‘a yazabiliyorsunuz; mesela frontend’in backend’den önce kurulması gerekiyorsa olay çocuk oyuncağı haline geldi:
services:
backend:
project: ./api
host: containerapp
frontend:
project: ./frontend
host: staticwebapp
uses:
— backend
Aklınız karışmasın; dağıtım esnasında otomatik olarak önce backend hazırlanıyor sonra frontend geliyor — üstelik ilave komut ya da başka orchestrator hikâyesi olmadan… Açık söylemem gerekirse Kasım ayında İstanbul’da büyük bir banka işi sırasında “sıra hatası” krizinden kafayı yiyordum – demek ki çözümü gözümüzün önündeymiş!
Neler Kolaylaştı?
- Zaman cepte kaldı; dependency sıralama derdi geçmişte kaldı sayılır.
- Ekip içinde “bugün deploy’u kim atacak” tartışmaları minimuma indi çünkü azd adeta dependency grafiğini çıkarıp kontrolü ele aldı.
- Dahası var—yanlış sıra riski azalınca hata anında gayet anlaşılır feedback dönüyor sisteme, acemi değilsen yakalıyorsun hemen nerede hata olduğunu.
- Küçük not bırakayım — çoklu zincirlerde bazen uyarılar fazla mekanik geliyor bana göre (“loop algıladım” diyip durdu iki üç kez), yine de ilerleyen sürümlerde rayına oturacak gibi hissediyorum… Hep birlikte göreceğiz bakalım nereye evrilecek.
Azd Publish ile Konteyner Akışı Artık Elinin Altında mı?
Beni esas heyecanlandıran yere gelelim mi? Yeni eklenen ‘azd publish’. Eskiden image pushlayacağımız zaman illa deployment akışıyla haşır neşir olup CI/CD pipe’larına kitlenmek şarttı — hani lokalden kodu itip anlık denemeler yapmak her zaman kolay değildi doğrusu… Şimdi ise ‘publish’ komutu tamamen bağımsız çalışıyor yani önce imajlarını Azure Container Registry’ye yollar, ardından gönül rahatlığıyla deployment işlemini başlatabilirsin! İnan bana bunun en büyük artısı development sürecindeki deneme-yanılmalarda çok net ortaya çıkıyor; test ortamları için can simidi resmen.
Buyurun bir örnek…
Docker Compose alışkanlığı olanlar varsa aramızda onlar için ilaç etkisi yaptı diyebilirim!
Madem laf açıldı kendi tecrübemi anlatmadan geçmem olmazdı—geçtiğimiz ay OpenAI API’sini kullandığımız web uygulamasında bizzat deneme fırsatı buldum (Mart başındaydık sanırım). Önce imajları registry’ye gönderdim sonra yalnızca kod değiştirerek tekrar deploy ettim… Hem CPU tüketimi %30 aşağıya çekildi hem de local registry üzerinden testler aksamadan devam etti.Burada minik dipnot düşeyim–authentication token dalgınlığınızdan unutursanız azd’ın verdiği error mesajları bazen kafa karıştırabiliyor.Biraz nefes alın paniğe kapılmayın diyorum ben :)
(ciddiyim)
Daha Gelişmiş Uzantılar ve Kimlik Doğrulamada Minik Ama Kritik Dokunuşlar
Azd dünyasında yeniliklerin ardı arkası kesilmiyor açıkçası… Extension tarafındaki üçüncü parti desteğinin hızlanmasıyla Codespaces veya VSCode üzerinden özel çözümler geliştirmek baya kolay hale geldi desem yeridir.Hatta authentication kısmına gelirsek,multi tenant destek hikâyelerinde artık saç baş yolma oranınız oldukça düştü(geçmişte vardı yani). Ufak tefek edge case hataları hala denk gelebiliyor lakin son yamalar cidden toparlamış durumda…
Burada →
Kritik İki Eksik/Küçük Sürprizler :
- Lokal VSCode’unuz extension marketle uyumsuzsa işler biraz sarpa sarabiliyor—özellikle yeni çıkan uzantıları yükleyince dikkat etmek lazım!
- Kullanıcı adıyla tenant arasında geçiş yaptığınız anlarda oturumunuz beklenmedik şekilde kopabilir—ben Nisan ortasında birkaç gece bu tuhaflığı yaşadığım oldu.Hemen tekrar login olun sorun çözülüyor ama sinirinizi bozabilir…
- Azd publish sonrası rollback senaryosu konusunda hala istediğim kadar özgür hissetmiyorum.Yani hayalimde daha çevik olmasını bekliyordum.Umarım yeni versiyonlarda ona da el atarlar!
Cep Telefonu Kadar Kolay Altyapı Yönetimi Mümkün mü? Evet Yaklaştık!
Eylül’de Logosoft cloud takımının haftalık toplantısındaydık,biri hafifçe gülerek ortaya şöyle bi soru attı:“Abi ileride bunların hepsini telefondan yönetebilecek miyiz sence?” Abartmak istemem. Layered provisioning + otomasyon kombinasyonu o derece stabil gidiyor ki,yarın mobil client’tan environment tetiklersem pek şaşırtmaz beni.Ozellikle FinOps işleri üzerinde,belli layer’ları tazeleyip kalan alanlara dokunmadığında maliyet açısından gerçek avantaj sağlıyor.Valla yıllardır bütçe dostu bulut dediğimiz şeyi şimdi hissetmeye başladığımı söylemeliyim.
Daha Fazla Okumak İsteyenlere Tavsiye :
- Azure Developer CLI Kasım 2025 üzerine şuraya bakabilirsiniz…
- Bir önceki CLI gelişmeleri detaylı burada…
- Azure SDK’daki yeniliklerden geri kalmayın diye bıraktığım link…
Şaka maka beklentimin ötesine geçtiler bu turda.Yolu halen uzun tabii ama haritaya bakınca umutsuz olmak elde değil.
Sonuç mu? Karmaşıklığa Son Vermek İçin Gerçek Adımlar Atılmış Görünüyor
- Ekipler arası yönetimde standardizasyon sağlanıyor,
- Bicep tabanı tutarlı biçimde kuvvetleniyor,
- Sürpriz aksaklıklara karşı tahmin edilebilir çözümler getiriyor,
- Ufak pürüzleri kenara koyarsak genel tabloyu olumlu yönde oynatmayı başarıyor!
.
İçeriği paylaş:
Yorum gönder