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ım

Komut 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.ps1

Garip 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:
— network

Bununla 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.

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 `

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

DevOps’ta Güvenlik Uyarılarıyla İş Öğesi Bağlama13 Mar 2026

GitHub Copilot Cloud Agent İçin Runner Kontrolü: Kurumsal Düzen3 Nis 2026

Azure’da NVIDIA ile Yeni Dönem: Foundry, Fiziksel AI ve Altyapıda Sıçrama17 Mar 2026

Birden Fazla Veritabanını Tek API ile Bağlamak: Data API Builder’ın Multi-Source Sihri26 Mar 2026