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)
İşin garibi, Bu ay azd tam beş sürüm yayınladı: 1.23.14, 1.23.15, 1.24.0, 1.24.1 ve 1.24.2. Sayıya bakıp “ne kadar çok” demeyin; asıl mesele sürüm sayısı değil, içerik tarafı. Şimdi gelelim hangi yeniliğin kimin işine yaradığına, kim neyi cebine koyar, önü konuşalım.
Çok konuştum, örnekle göstereyim.
En Büyük Değişiklik: Hook’lar Artık Bash’in Esiri Değil
Şunu söyleyeyim, Şunu açık açık söyleyeyim: azd‘nın hook sisteminden ben de epey şikayet ediyordum. Bash ya da PowerShell, ikisinden birini seçmek zorundasınız; başka yol pek yoktu. Geçen yıl bir e-ticaret müşterinde Python ile yazılmış bir veri seed scripti vardı, önü hook’a yedirmek için preprovision hook’ünün içinden python script.py diye cagiriyorduk. Çok temiz durmuyordu, evet, ama çalışıyordu. Neyse uzatmayalım.
Şöyle söyleyeyim, Nisan sürümüyle is değişti. Artık hook’larınızı doğrudan Python, JavaScript, TypeScript veya.NET ile yazabiliyorsunuz. Üstelik bağımlılık işi de otomatik ilerliyor, yanı requirements.txt varsa azd bir virtual environment oluşturup paketleri kuruyor; package.json gorurse npm install çalıştırıyor.cs dosyası varsa da dotnet run ile peşine düşüyor. Kısa versiyon bu.
Pratikte Nasıl Gözüküyor?
Bir örnek vereyim. Diyelim ki provision sonrası Cosmos DB’ye seed data atmak istiyorsunuz. Eskiden şunu yazıyordunuz:
hooks:
postprovision:
shell: sh
run: |
pip install -r requirements.txt
python seed.pyPeki sonra ne oluyor? Şimdi direkt böyle gidiyorsunuz:
hooks:
postprovision:
run:./scripts/seed.py
config:
virtualEnvName:.venv-azdBak şimdi, Fark baya hissediliyor, değil mi? Hatta bana kalırsa asıl hoş tarafı config bloğu. JavaScript tarafında packageManager var, yanı yarn mi pnpm mi seçeceğiniz belli.NET tarafında configuration ve framework ayarlanabiliyor; TypeScript scriptleri de compile aşamasına takılmadan npx tsx üzerinden doğrudan koşuyor. Bu kısım biraz sessiz ama bayağı iş görüyor.
.NET 10 ile gelen single-file script desteği sayesinde tek bir
.csdosyası ile hook yazabiliyorsunuz. Ben bunu ilk denediğimde “yahu bu Python kadar pratik olmuş” dedim. Project file falan gerekmiyor.
Türkiye’deki Ekipler İçin Bu Ne Anlama Geliyor?
İtiraf edeyim, Burada bir parantez açayım. Kurumsal müşterilerde gördüğüm tablo biraz böyle: Türkiye’de azd benimsemesi ağır ağır ilerliyor, hatta bazen insan “neden bu kadar yavaş?” diye düşünüyor; (bu beni çok şaşırttı). Işin aslı şu, çoğu büyük şirket hâlâ Terraform ya da ARM template ile gidiyor, üstüne kendi shell script’lerini de ekleyince mevcut düzeni bir anda bozmak istemiyorlar.
Evet. azd‘ye geçmek, sadece bir araç değiştirmek değil, otomasyonu baştan düşünmek demek (evet, doğru duydunuz). Ama şu çok dilli hook meselesi var ya, bence burada oyun biraz değişiyor; çünkü bir bankacılık projesinde şunu net gördüm: ekipte 3 kişi Python biliyordu, 2 kişi C# yazıyordu, Bash bilen tek kişi vardı ve o arkadaş da DevOps tarafında sürekli koşturuyordu (hatta arada “ben hastayım” diye laf atıyordu), yanı geliştiricinin kendi dilinde hook yazabilmesi işi baya kolaylaştırıyor.
Peki neden?
Bir de küçük startup tarafı var. Orası zaten azd‘yi seviyordu, çünkü az lafla çok iş çıkarıyor; şimdi enterprise tarafı da — özellikle.NET ağırlıklı çalışan finans ve telekom ekipleri — buna daha rahat yanaşabilir gibi dürüyor. Açık konuşayım, biz de Logosoft’ta bir Azure göç projesinde bunu denemeyi planlıyoruz; sonuçları görünce yazarım (yanlış duymadınız)
Kısacası, peki neden? Çünkü ekip içinde herkes aynı dili konuşmuyor (yanlış duymadınız)
AI Quota Preflight: Hayatımı Kurtaran Özellik
Doğrusu, Şimdi gelelim benim için bu sürümün en sevindirici tarafına. azd, AI model deployment’larını provision etmeden önce artık quota kontrolü yapıyor. Geç kaldın ama iyi öldü, açık konuşayım.
Bunun neden bu kadar can alıcı olduğunu anlatayım. Geçen Şubat’ta bir müşteride GPT-4 deployment’ı açacağız, azd up dedik. 12 dakika sonra “InsufficientQuota” hatasıyla rollback yedik. Tam 12 dakika boşa gitti, yanı insanın içi cız ediyor. Daha önce GPT-5.5. Microsoft Foundry: Kurumsal AI Artık Ciddi yazısında da değinmiştim; bölge bazındaki quota limitleri çoğu zaman default’ta düşük geliyor, işte asıl dert de burada başlıyor.
Yeni preflight check ne yapıyor peki? Deployment’ı başlatmadan önce hedef bölgedeki quota’yı kontrol ediyor, yetmiyorsa pat diye hata fırlatmak yerine uyarı veriyor. Sonra başka bölge öneriyor ya da quota artırma talebi için yönlendiriyor, hani kullanıcıyı ortada bırakmıyor. Basit gibi dürüyor ama dur bir saniye — bana sorarsanız 1.24.0’ın en işe yarar yeniliği bu olabilir.
azd update: Kendini Güncelleyen CLI Devri
Daha önce azd‘yi güncellemek istediğinizde, kurulum şekline göre ayrı ayrı komutlarla uğraşmanız gerekiyordu. Windows’ta MSI’yi yeniden indiriyorsunuz, macOS’ta brew upgrade diyorsunuz, Linux tarafında işe curl ile başka bir yol izliyordunuz; açık konuşayım, biraz yorucuydu.
Şimdi iş değişti. azd update geldi ve public preview’a geçti. Hangi platformda olduğunuz çok fark etmiyor, hangi yöntemle kurduğunuz da öyle; tek komutla son sürüme çıkıyorsunuz. Basit dürüyor, evet, ama büyük ekiplerde onlarca developer’ın aynı sürümde kalmasını sağlamak için baya iş görüyor. Bu konuyla ilgili Kubernetes v1.36 Memory QoS: Katmanlı Bellek Koruması Geldi yazımıza da göz atmanızı tavsiye ederim.
Peki neden önemli? Çünkü sürüm farkı büyüyünce işler çorba oluyor. Bir kişi yeni davranışı görüyor, diğeri eski CLI ile takılıyor (sonra “bende çalıştı” tartışması başlıyor), işte o noktada bu küçük gibi duran özellik ciddi rahatlık sağlıyor. Daha fazla bilgi için Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşiyor yazımıza bakabilirsiniz.
Güvenlik Tarafında Sessiz Ama Önemli Düzeltmeler
Windows tarafında bir de MSI code-signing verification eklenmiş. Yanı MSI paketinin imzası artık doğrulanıyor. Küçük bir detay gibi dürüyor ama değil; supply chain saldırıları yüzünden bu tip kontrollerin değeri baya arttı. Hatırlarsanız geçen ay Axios npm Saldırısı: Azure Pipelines’ta Ne Yapmalı? başlıklı yazımda npm tarafındaki saldırıyı ele almıştım — işin aslı, bu konu artık “bir ara bakarız” denecek yerde değil.
Ha, bir de extension komutlarında environment variable leak fix’i var. Detaylar release notes’ta yazıyor. Özet şu: bazı edge case’lerde extension komutları parent process’in env değişkenlerini yanlışlıkla loglara sızdırabiliyormuş. Şey… hoş değil tabiî. Düzeltmişler.
Açık konuşayım, ben bu tip sessiz düzeltmeleri seviyorum. Gösterişli görünmüyorlar ama sahada can sıkıntısını azaltıyorlar (hele ki pipeline’lar ve otomasyon akışları büyüdüyse). Bu yüzden hızlıca güncellemekte fayda var.
Extension Framework: Custom Provisioning Provider’lar
Bu kısım biraz extension yazanları ilgilendiriyor, ama kurumsal tarafta çalışanlar için de boş bir detay değil. WithProvisioningProvider("name", factory) ile kendi infrastructure backend’ınızı azd‘ye plugin gibi takabiliyorsunuz, yanı işin aslı biraz “benim altyapı katmanım da var” diyen ekipler için kapı aralanıyor. Teams Agent Kurulumu Artık Tek Komutla Tamam yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Service Bus Batch İşlemede Mesaj Bazlı Settlement Devrimi yazımıza da göz atmanızı tavsiye ederim.
Ş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. Bu konuyla ilgili Gateway API v1.5: Altı Özellik Stable Oldu, Ne Değişiyor? yazımıza da göz atmanızı tavsiye ederim.
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" data-glossary-term="Azure OpenAI Service">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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder