Azure Developer CLI Mayıs-Haziran 2026: azd tool ve exec Devrimi
azd ile uzun zamandır iç içeyim. İlk çıktığında — hatırlıyorum — “bu da bir şey mi ki?” diye biraz burun kıvırmıştık — itiraf edeyim, beklentimin üstündeydi —. Sonra bir baktık, ekipteki herkes azd up diyerek bir Container Apps ortamını dakikalar içinde ayağa kaldırıyor. Şimdi geldiğimiz nokta işe bambaşka. Mayıs. Haziran 2026 döneminde tam dokuz sürüm arka arkaya geldi: 1.24.3’ten başlayıp 1.26.0’a kadar uzandı. Hepsini tek tek anlatmak sıkıcı olur, açık konuşayım, kimse de sonuna kadar okumaz. Ben size sahada gerçekten fark yaratanları, kendi kafamdaki önem sırasına göre anlatacağım.
Lafı gevelemeden söyleyeyim: Bu iki ayın en büyük iki yeniliği azd tool ve azd exec. Geri kalanların çoğu bunların etrafında dönen iyileştirmeler gibi dürüyor. Ama bir de Container Apps tarafında, beni şahsen epey yoran bir bug nihayet kapanmış. Ona da geleceğim, merak etmeyin.
azd tool: Önkoşul cehennemine son mu?
Şöyle bir sahne gözünüzün önüne gelsin. Yeni biri ekibe katılıyor. “Hadi şu template’i deneyelim” diyorsunuz. Çocuk azd up yazıyor. Hop, Bicep CLI yok. Hallediyor. Tekrar deniyor. Bu sefer Docker daemon kapalı çıkıyor. Önü da açıyor. Bir daha deniyor, bu kez GitHub CLI eksik oluyor. Ve böyle uzayıp gidiyor… İki saate yakın süren bir “ön kurulum töreni” başlıyor işte.
azd tool komut grubu tam buna çözüm olarak gelmiş gibi dürüyor. Artık şunları yapabiliyorsunuz:
azd tool list # Bu template hangi araçları istiyor?
azd tool install # Eksik olanları kur
azd tool check # Hepsi güncel mi?
azd tool upgrade # Güncelle bakalımKomut grubu artık alpha’dan çıkmış, varsayılan olarak açık geliyor. Yeni kullanıcılar için bir de “first-run welcome” deneyimi var; yanı azd‘yi ilk kez kuran biri açtığında önü kısa bir tür attırıyor, “Şunlar lazım, ister mısın kurayım?” diye soruyor. Kulağa basit geliyor ama işin onboarding tarafını bayağı değiştirir gibi.
Bir de güzel sayılabilecek bir detay var: azd tool check artık önbelleğe yaslanmıyor. Doğrudan paket yöneticilerine, eklenti registry’lerine ve VS Code Marketplace’e sorup güncel sürümü öğreniyor. Yanı “her şey güncel” derken size sallamıyor.
Azure Skills: Agentic CLI hostları için ekstra katman
1.25.4 ile gelen azd tool install azure-skills komutu bence ilginç taraflardan biri öldü. Copilot CLI, Claude Code gibi agentic CLI hostlarına Azure becerilerini ekliyor. Sizin AI ajanınız Azure işleri konusunda biraz daha ne yaptığını biliyor hâle geliyor. Bunu Türkiye’deki şirketler açısından düşününce, Copilot lisansı olup ajan tarafında ne yapacağını şaşıran ekipler için fena olmayan bir başlangıç noktası çıkıyor ortaya.
Eğer bu tarafın mimarı kısmı da ilginizi çekiyorsa, konuyu biraz daha geniş anlattığım Agent Framework ile Claw Mimarisi: İlk Ajanı Üç Adımda Kurmak yazıma bakabilirsiniz; orada işin çerçevesini biraz daha açmıştım (şaşırtıcı ama gerçek)
azd exec: Çapraz platform script çalıştırma
Bana kalırsa bu dönemin sessiz devrimi bu komut olmuş. Çok konuşulmadı ama hayat kurtarıyor.
Bence, Senaryo tanıdık: Elinizde bir Bash script var. İçinde $AZURE_KEY_VAULT_NAME gibi değişkenler kullanıyorsunuz. Bunu çalıştırmak için önce azd env get-values, sonra export, sonra script tetikleme derken uğraşıyordunuz. Hele Windows tarafındaysanız… eh işte, biraz çileye dönüyordu.
Açıkçası, azd exec bu hikâyeyi bayağı toparlıyor:
azd exec --./deploy-extras.sh
azd exec — python migrate.py
azd exec --shell powershell --./post-deploy.ps1Garip gelecek ama, Peki içeride ne oluyor? Komutu, azd environment’ının tamamıyla — Key Vault secret çözümlemesi dahil — donatıp çalıştırıyor. Windows, macOS, Linux fark etmiyor. Hooks yazmaya gerek kalmıyor, kendi shell wrapper’ınızı üretmeye de gerek kalmıyor. İş görür mü? Görüyor gibi.
Sahada şunu çok görüyorum: Ekipler post-deploy adımlarını ya CI/CD pipeline’ına gömüyorlar (o zaman lokal test zorlaşıyor), ya da Makefile gibi araçlarla sarıp sarmalıyorlar (bir süre sonra kimse dokunmak istemiyor).
azd exec, bu ikisinin arasındaki boşluğu doldurmuş gibi dürüyor.
Multi-layer provisioning: dependsOn nihayet açık
Burası eskiden biraz dolambaçlıydı, hatta yer yer sınır bozucuydu da diyebilirim. Birden fazla Bicep katmanınız varsa — mesela — ki bu tartışılır — “shared”, “network”, “app” gibi — hangisi hangisinden önce gelecek diye azd‘nın bunu sezmesini bekliyordunuz. Bazen tutuyordu, bazen tutmuyordu; bazen de iki katmanı paralel kuralım derken Azure’daki dependency ilişkisini atlayabiliyordu.
Bir dakika — bununla bitmedi.
azure.yaml içine artık açık bir dependsOn alanı geliyor: (buna dikkat edin)
infra:
layers:
network:
path: infra/network
app:
path: infra/app
dependsOn:
— networkBununla birlikte dependency analizi de daha güvenli hâle getirilmiş durumda; yanı azd, “ben akıllıyım, kendim çözerim” havasından biraz çıkıp işi size bırakıyor diyebiliriz (iyi anlamda). Açık, deterministik ve debug edilebilir olması hoşuma gitti açıkçası.
Ctrl+C ile interaktif iptal: Küçük ama altın değerinde
Ne yalan söyleyeyim, Bunu yaşamayan pek anlamaz zaten.
azd provision‘ı başlattınız diyelim.
Yarısında “of, parametreyi yanlış verdim” dediniz.
Ctrl+C bastınız.
Sonra ne öldü?
Doğrusu, Daha önce Azure tarafında deployment devam edebiliyordu. Sız çoğu zaman bunun farkına bile varmıyordunuz; ertesi gün faturayı görünce insanın yüzü düşüyordu resmen.
Artık azd provision ve azd up sırasında Ctrl+C bastığınızda size soruyor: (yanlış duymadınız)
- Azure’daki deployment’ı devam ettireyim mi?
- Yoksa önü da iptal edeyim mi?
Küçük bir ayrıntı gibi görünüyor olabilir. FinOps tarafından bakınca hiç küçük değil aslında (özellikle yanlışlıkla saatlerce çalışan AKS deployment’ları düşünün). Türkiye’de TL bazlı bütçeler. Kur etkisi de üstüne binince, bu tarz “yanlışlıkla bırakılmış” kaynaklar danışmanlık verdiğimiz firmalarda fatura analizinde sık çıkan kalemlerden biri oluyor.
Container Apps concurrency fix: Nihayet!
Beni şahsen en çok sevindiren düzeltme burası öldü galiba.
Container Apps’e paralel deployment yaparken — özellikle ACR remote build kullanıyorsanız — servisler arasında image contamination, yanı imaj karışması yaşanabiliyordu. Daha fazla bilgi için
A servisini deploy ederken B servisinin image’ı yanlışlıkla A’ya yapışabiliyordu; çok nadir görülüyordu. Olduğunda saatlerinizi yiyen cinsten bir bug’tu bu, insanın “neden bu container şimdi bunu çalıştırıyor?” diye bakakalmasına yol açıyordu.
Evet.
Açıkçası, Tam da öyle. (evet, doğru duydunuz)
Neyse ki kapandı.
İtiraf edeyim, Kurtulduk gibi.
Sürümlerin 1.25.x hattında bu sorun kapatılmış durumda; aslında tek bir düzeltme değil, birkaç concurrency fix var burada (ACR build tag çakışması, paralel push sırasında manifest karışıklığı gibi şeyler). Hani ne farkı var diyorsunuz, değil mi? Eğer microservice mimarisinde 5+ servisi tek azd up‘la deploy ediyorsanız, bu güncellemeye geçmek için beklemeye pek gerek yok bence.
Burası önemli mi? Go desteği Azure Functions için geldi
Evet, geldi.
Azure Functions tarafında Go nihayet first-class vatandaş öldü diyebiliriz — en azından `
Sıkça Sorulan Sorular
azd tool ile asdf, mise, brew arasındaki fark ne?
asdf ya da mise hani dil sürümü yönetimi için kullanılıyor, çok daha genel araçlar bunlar. azd tool ise aslında farklı bir şey — azd'nin ve template'inizin spesifik olarak ihtiyaç duyduğu Azure odaklı araçları yönetiyor: Bicep CLI, Azure Functions Core Tools, GitHub CLI, ilgili VS Code eklentileri gibi. Birbirinin rakibi değiller yani, ikisini üst üste kullanabilirsiniz.
Peki neden?
azd exec, hooks özelliğinin yerini mi alıyor?
Daha açık söyleyeyim, garip gelecek ama, Hayır. Hooks hâlâ hayatta ve event-driven senaryolar için (preprovision, postdeploy vs.) doğru seçenek olmaya devam ediyor. azd exec ise daha çok şöyle düşünün: elle, istediğiniz bir anda bir script'i azd context'iyle çalıştırmak istediğinizde devreye giriyor. Açıkçası lokal test sırasında ve ad-hoc işlerde bu çok işe yarıyor.
Mevcut azure.yaml'larım 1.26.0'da bozulur mu?
İtiraf edeyim, Hayır, geriye dönük uyumluluk korunmuş. dependsOn alanı opsiyonel — tanımlamazsanız eskisi gibi otomatik dependency tahmini devreye giriyor. Yani yeni bir zorunluluk yok, sadece açıkça tanımlamak isteyenler için bir kapı açılmış. Yine de bence production'a geçmeden önce staging'de bir azd provision --preview çalıştırmanızda fayda var.
Self-contained extension bundle güvenlik açısından riskli mi?
Size bir şey söyleyeyim, Hem evet hem hayır, aslında. Registry olmadan dağıtım, supply chain kontrolünü tamamen size bırakıyor — yani imzalama ve hash doğrulama gibi süreçleri kendiniz kurmanız gerekiyor. Air-gapped kurumlar için bulunmaz bir fırsat bu, ama "internetten indirip kurdum" diyen biri için mesela ciddi bir risk. Kurumsal politikanıza göre değerlendirin.
Production CI/CD'de hangi azd sürümünü pin'lemeliyim?
Eh, Şu an için 1.26.0'ı öneriyorum. Tüm concurrency fix'leri içeriyor, azd tool stable, güvenlik düzeltmeleri de tam. Daha eski bir sürümde kalmak için özel bir sebebiniz yoksa buraya geçin. Tecrübeme göre pipeline'da minor sürüm bazında pin'lemek (mesela 1.26.x) mantıklı — böylece patch güncellemelerini otomatik alıyorsunuz.
Kaynaklar ve İleri Okuma
Azure SDK Blog – azd May & June 2026 Round-up
Azure Developer CLI Resmi Dokümantasyonu
azd GitHub Releases — Tüm Sürüm Notları
azd Komut Referansı (tool, exec, provision dahil) (buna dikkat edin)
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.
2 comments