Azure Developer CLI Nisan 2026: Çok Dilli Hook Devri Başladı
Açık konuşayım: azd‘yi ilk çıktığında biraz şüpheyle karşılamıştım. “Yine bir CLI mi?” demiştim. Microsoft’un her ay yeni bir komut satırı aracı çıkardığı dönemdi, hatırlarsanız. Ama Nisan 2026 sürümlerini kurcalayınca fikrim baya değişti; özellikle hook tarafındaki yenilikler, işin havasını sessiz sedasız başka yere çekiyor (kendi tecrübem)
Şunu fark ettim: Bak şimdi, şirketinizde Pulumi tabanlı iç bir altyapı katmanı olduğunu düşünün. Eskiden azd tarafında seçenekler daha dardı; Bicep ve Terraform ile yürüyordunuz. Şimdi işe kendi sağlayıcınızı yazıp azure.yaml içinde infra: { provider: pulumi-internal } diyebiliyorsunuz, bu da özellikle büyük organizasyonların kendi DevOps platformunu azd ile yan yana getirmesini baya kolaylaştırıyor.
azd‘nın kendisi GA. Yanı çekirdek aracı production’da rahatça kullanabilirsiniz; sadece extension yazıyorsanız Beta tarafındaki sınırlamalara göz atmanız iyi olur.
–no-prompt Standardizasyonu: CI/CD ve AI Agent’lar İçin
Bu küçük gibi görünen değişiklik, açık konuşayım, baya işe yarıyor (yanlış duymadınız). --no-prompt bayrağının davranışı artık tüm komutlarda aynı çizgiye geldi; eskiden bazı komutlar bunu yok sayıyordu, bazıları da yarım yamalak destekliyordu. Şimdi en azından tutarlılık var.
Peki neden? İki sebep var. İlki biraz klasik, ikincisi işe yeni yeni hayatımıza iyice giriyor; yanı işin aslı sadece komut satırı meselesi değil, otomasyonun nerede tıkandığıyla da ilgili.
- CI/CD pipeline’lar: Azure DevOps ya da GitHub Actions üstünde
azdkomutu çalıştırırken araya interaktif bir prompt girerse, pipeline orada kalıyor, bekliyor, sonra sınır bozucu şekilde zaman yiyor.--no-promptile artık bu akış daha net oluyor; fail-fast davranışı daha güvenilir hâle geliyor. - AI agent’lar: Copilot ya da kendi ajan sistemlerinizin
azdçağırması artık pek şaşırtıcı değil. Ama bu agent’lar oturup prompt’a cevap veremiyor, tabi burada sürpriz yok. Davranış standardize olunca entegrasyon tarafı daha öngörülebilir oluyor, bazen ufak bir detay bütün sistemi rahatlatıyor.
Bir şey dikkatimi çekti: Neyse, çok dağıtmayayım. Bu tip standartlaşmalar dışarıdan ufak görünür ama pratikte ciddi fark yaratır (ben de ilk duyduğumda şaşırmıştım). En çok da de otomasyonla uğraşıyorsanız, böyle şeyler bir gününüzü kurtarabiliyor.
Sürümler Arasında Hangi Değişiklik Hangi Versiyonda?
Ne yalan söyleyeyim, Bir özet tablo çıkarayım, kafanız karışmasın (evet, doğru duydunuz). E peki, sonuç ne öldü? Çünkü sürüm notları bazen insanı gereksiz yere yoruyor, hani küçük gibi duran bir değişiklik sonra bir bakıyorsunuz bütün akışı etkiliyor (özellikle extension tarafında böyle şeyler daha sık çıkıyor), o yüzden ben bunu net bir tabloya dökmeyi seviyorum.
| Sürüm | Öne Çıkan Değişiklik |
|---|---|
| 1.23.14 | MSI code-signing doğrulaması, küçük güvenlik fix’leri |
| 1.23.15 | Extension komutlarında env variable leak fix |
| 1.24.0 | Multi-language hooks, AI quota preflight, custom provisioning providers |
| 1.24.1 | azd update public preview, –no-prompt standardizasyonu |
| 1.24.2 | Per-layer hooks, azd hooks run --layer bayrağı |
Kısacası olay şu: 1.23.14 tarafında iş biraz güvenlik ve doğrulama ekseninde dönüyor, 1.23.15’te işe extension komutlarında environment variable sızıntısı düzeltilmiş oluyor; bu arada kulağa ufak geliyor ama pratikte can sıkıcı bir detaydı.
Bir dakika — bununla bitmedi.
Sonra 1.24.0 geliyor ve iş biraz açılıyor; multi-language hooks, AI quota preflight ve custom provisioning providers gibi parçalar devreye giriyor, yanı burada artık sadece düzeltme değil, kullanım senaryosunu genişleten şeyler de var.
Evet.
1.24.1’de azd update public preview’a çıkıyor ve --no-prompt davranışı da standardize ediliyor; açık konuşayım, bu tip tutarlılık işleri ilk bakışta sıkıcı dürüyor ama sonradan baya iş görüyor (buna dikkat edin)
Neyse uzatmayayım, 1.24.2’de de per-layer hooks geliyor ve azd hooks run --layer bayrağı ekleniyor; yanı hook çalıştırma tarafı biraz daha ince ayarlı hâle geliyor.
Kısacası, bir şey dikkatimi çekti: Peki neden önemli? Çünkü sürüm bazında neyin nerede geldiğini bilmezseniz, bir davranış değiştiğinde önce Azure mı bozuldu diye düşünüyorsunuz, sonra meğer güncelleme notunda minicik bir satır kaçmış oluyor.
Tam da öyle.
Eksik Bulduğum Taraflar
Her şey toz pembe değil tabiî. Şunu net söyleyeyim: hook’larda Go desteği hâlâ yok, bu da cloud-native tarafta Go ile yaşayan ekipler için biraz can sıkıyor; biz de bazı internal tool’larımızı Go ile yazıyoruz, o yüzden bu boşluğu baya hissettim. “Java desteği geldi mi?” diye sorarsanız, hayır, o da yok; Java tarafı sadece deployment hedefi olarak dürüyor, hook yazımı için değil (şaşırtıcı ama gerçek). Kısacası durum bu.
Bir de azd update public preview’da. Yanı production’da kritik pipeline’lara sokmadan önce iki kere bakmak lazım, hatta ben olsam bir üçüncü kez daha kontrol ederim. Preview etiketi bazen ufak sürprizler çıkarabiliyor (özellikle işin içine otomasyon girince). GA olmasını beklerim açıkçası.
Pratik Geçiş Rehberi: İlk Adımlar
Bunu yaşayan biri olarak söyleyeyim, Eğer azd‘yi mevcut projenizde kullanıyorsanız ve bu yeniliklerden faydalanmak istiyorsanız, işin başında çok kasmaya gerek yok; ama yine de sırayı bozmayın:
- Önce
azd versionile mevcut sürümünüzü kontrol edin. 1.23.14’ün altındaysanız genelde güncelleyin (güvenlik fix’i için), çünkü bu tip detayları sonradan yakalamak insanı uğraştırıyor. - Bash hook’larınızdan birini deneme amaçlı Python’a çevirin. Küçük bir post-deployment hook iyi bir başlangıç oluyor; hem risk az kalıyor hem de davranışı canlıya çıkmadan görebiliyorsunuz.
- AI deployment’ı varsa, 1.24.0’a geçtikten sonra preflight check’in çalıştığını doğrulayın. Burada “çalıştı herhalde” demek yetmiyor, log’a bakın; bazen insan gözden kaçırıyor.
- CI/CD pipeline’larınızda
--no-promptbayrağını ekleyin. Zaten ekliydi diyorsanız, davranışın değişmediğini test edin; çünkü küçük bir prompt farkı bile otomasyonu gereksiz yere durdurabiliyor.
Neyse, çok dağıtmadan devam edeyim: DevOps tarafını biraz daha derinlemesine düşünüyorsanız, Azure DevOps Git Policy Yönetimi: 10x Hız Kazanmanın Yolu yazısı da işinize yarayabilir — özellikle pipeline standardizasyonu konusunda, yanı düzeni biraz toparlamak isteyenler için fena değil.
Maliyet Tarafına Bir Bakış
azd‘nın kendisi ücretsiz, ama provision ettiği kaynaklar tabiî ki ücretsiz değil. Türkiye’deki müşterilerime hep şunu söylüyorum: azd up komutunu çalıştırmadan önce --preview bayrağıyla bir bakın ne kuracak, sonra da azd provision --preview ile maliyet tahminine göz atın. Yoksa ay sonu fatura gelince insan bir durup kalıyor, “ya ben bunu nereden gördüm” deme hali var.
Bir bakıma, şunu fark ettim: Bir de şu yeni hook sistemi var ya, orada küçük (bizzat test ettim). Sınır bozucu bir detay çıkabiliyor: Python virtual environment ilk çalıştırmada kurulurken CI/CD pipeline’ınızı 30-60 saniye uzatabiliyor. Baya iş görüyor,. Ilk anda can sıkıyor; o yüzden cache mekanizmalarını devreye almayı unutmayın (yoksa her koşuda aynı beklemeyi tekrar tekrar izlersiniz). Evet.
İşte tam da bu noktada devreye giriyor.
Sıkça Sorulan Sorular
azd, Terraform veya Bicep’in yerini mi alıyor?
Hayır, almıyor. azd aslında bunların üstünde çalışan bir orkestrasyon katmanı. Yanı Bicep ve Terraform’u backend olarak kullanıyor. Mesela Bicep ile yazdığınız altyapı kodunu azd ile çalıştırıyorsunuz; deployment, environment yönetimi, hook’lar gibi şeyleri de azd hallediyor (buna dikkat edin). Bence bu ayrımı anlamak çok önemli.
Mevcut Bash hook’larımı Python’a çevirmek zorunda mıyım?
Tartışmasız hayır. Bash ve PowerShell desteği aynen devam ediyor. Sadece yeni diller eklendi. Açıkçası, ekibinizde Bash bilgisi güçlüyse hiç dokunmayın işine. Yeni dilleri merak ediyorsanız, yeni hook’larda denersiniz — acele eden yok.
azd update komutu hangi platformlarda çalışıyor?
Windows (MSI), macOS (brew. Installer), Linux (apt, — kendi adıma konuşayım — rpm, curl install) — yanı hani tüm desteklenen platformlarda public preview olarak geliyor. Ama şunu unutmayın: public preview. Tecrübeme göre bu tür şeyleri üretim CI/CD’sine otomatik bağlamadan önce mutlaka test etmek lazım.
AI quota preflight check hangi modelleri destekliyor?
Azure OpenAI Service üzerinden deploy edilen tüm modellerde çalışıyor — GPT-4, GPT-4o, GPT-5 ailesi, embedding modelleri dahil. Foundry üzerinden gelen üçüncü parti modellerde davranış biraz farklı olabiliyor; o yüzden orada dökümanı bir kontrol edin derim.
Kısa bir not düşeyim buraya.
Custom provisioning provider yazmak için hangi dilleri kullanabilirim?
Şu an için Go ve.NET var. Provider’ı extension içinde tanımlıyorsunuz, bu yüzden extension framework’ün desteklediği dillerle sınırlısınız. Python ve TypeScript yol haritasında var ama henüz çıkmadı — biraz sabır lazım.
Kaynaklar ve İleri Okuma
Azure Developer CLI (azd) – April 2026 Release Notes
Azure Developer CLI Resmî Dokümantasyonu
Azure/azure-dev GitHub Reposu
azd Extension Framework Dokümantasyonu
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.
3 comments