azd Nisan 2026: Multi-Language Hooks ve Sessiz Devrim

Geçen hafta bir müşteride azd‘nın yeni hook sistemiyle uğraşırken aklıma yine aynı şey geldi, bu araç son bir yılda sessiz sedasız büyümüş. Çoğu ekip hâlâ önü sadece “şablon deploy eden bir CLI” sanıyor,. Işin aslı biraz daha karışık (ve bence daha ilginç), çünkü Nişan 2026 sürümleriyle birlikte tablo ciddi şekilde değişti.

Size bir şey söyleyeyim, Hani bazen Microsoft bir şeyi öyle aradan çıkarır ki, önce kimse dönüp bakmaz, sonra bir bakarsın herkes kullanmaya başlamış. azd tam oraya geldi gıbı. Evet. Nişan ayında tam beş release gelmiş: 1.23.14, 1.23.15, 1.24.0, 1.24.1 ve 1.24.2 (ciddiyim). Ama açık konuşayım, hepsini tek tek didiklemeyeceğim; ben burada sahada gerçekten iş görecek olanları ayıklayacağım, çünkü bazı feature’lar kağıt üstünde iyi duruyor ama pratikte insanı yarı yolda bırakabiliyor.

Ana Mesele: Hook’lar Artık Çok Dilli

Yıllardır azure.yaml içine hook yazarken iki yol vardı: Bash ya da PowerShell. Linux tarafı Bash’e yaslanıyordu, Windows ekibi de PowerShell’e; çapraz platform bir şey gerektiğinde işe aynı işi iki kez yazıyorduk,. preprovision için bir Bash, bir de PowerShell hazırlamak zorunda kalıyorduk. İşin aslı, sürdürülebilirlik açısından pek iç açıcı değildi.

Şimdi tablo değişmiş durumda. Python, JavaScript, TypeScript ve.NET hook’ları doğrudan destekleniyor. Projeniz Node tabanlıysa — bugün epey ekip öyle çalışıyor zaten — hook’ları TypeScript ile yazabiliyorsunuz; aynı dil, aynı tooling, aynı linter. Küçük bir detay gıbı duruyor ama değil, hani bazen tam da böyle şeyler günlük işi rahatlatıyor (bizzat test ettim)

Evet, doğru duydunuz.

Otomatik Bağımlılık Yönetimi

Güzel tarafı şu: azd, hook’u çalıştırmadan önce ortamı kendi hazırlıyor. Python için requirements.txt ya da pyproject.toml bulursa virtual environment kurup bağımlılıkları çekiyor; Node tarafında package.json varsa npm install devreye giriyor; TypeScript’te npx tsx ile compile etmeden çalıştırıyor.NET tarafında işe dotnet run üzerinden tek dosya script bile dönebiliyor (.NET 10+ üzerinde) (ben de ilk duyduğumda şaşırmıştım). Açık konuşayım, ilk duyduğumda “bu kadar mı?” dedim.

Logosoft’ta geçen ay bir e-ticaret müşterimizde tam bu dertle uğraşmıştık (bizzat test ettim). Provision sonrası Cosmos DB’ye seed data basmak için Python scripti yazmıştık ama bunu hook’a nasıl bağlayacağımız konusunda baya oyalandık; en sonunda Bash wrapper’a sarıp python3 seed.py çağırıyorduk. Bir yandan virtual env’i elle yönetiyorduk (tabii bu iş uzadıkça uzadı), diğer yandan Windows’taki developer arkadaşlarda doğal olarak patlıyordu. Şimdi aynı senaryo çok daha sade görünüyor:

hooks:
postprovision:
posix:
shell: python
run: scripts/seed.py
windows:
shell: python
run: scripts/seed.py
config:
virtualEnvName:.azd-venv

Evet. Bu konuyla ilgili DSC v3.2.0 Çıktı: Windows Resource’ları, Bicep ve Daha yazımıza da göz atmanızı tavsiye ederim.

Bitti gitti. Kulağa biraz basit geliyor ama burada tam olarak aradığımız şey bu zaten; neyse uzatmayalım, bu yaklaşım gerçekten baya iş görüyor.

Executor Konfigürasyonu

config: bloğu da fena değil, hatta beklediğimden daha düzenli duruyor. JS/TS için packageManager‘ı seçebiliyorsunuz (npm, pnpm, yarn — biz mesela pnpm kullanıyoruz), Python için yerine tabii ki doğru alan olan değil; şaka bir yana gerçek alan — durun, dağıtmayayım — Python’da yine değil ama siz ne demek istediğimi anladınız: virtual env adı veriyorsunuz,.NET tarafında da configuration ve framework ayarlarını belirleyebiliyorsunuz. Yanı yeni icat edilmiş şeyler değil bunlar; standart ihtiyaçlar ama dokümante edilmiş. Sürpriz çıkarmayan hâliyle geliyorlar.

Per-Layer Hooks: Infra’yı Katmanlara Bölmek

Şu özellik pek konuşulmuyor, ama işin aslı sahada farkı burada görüyorsunuz. infra.layers[].hooks altına koyduğunuz hook’lar artık azd provision sırasında sadece ait olduğu katmanda çalışıyor; bir de azd hooks run --layer foundation diyerek tek bir katmanı ayrı ayrı da tetikleyebiliyorsunuz. Kulağa sade geliyor, değil mi? Ama pratikte baya iş görüyor.

İnanın, Bunu Türkiye’deki şirketler açısından düşününce — özellikle bankacılık ve sigortacılık tarafında — tablo biraz daha netleşiyor. Infra’yı network, security, data ve app diye ayıran ekipler için bu yapı gerçekten yerinde duruyor; bizim bir bankacılık projemizde network katmanı CTO onayı isterken app katmanı dev ekibi rahatça deploy edebiliyordu, o yüzden şimdiye kadar Bicep modüllerini ayrı ayrı deploy edip azd‘yi biraz kenarda tutuyorduk (evet, doğru duydunuz). Şimdi durum değişiyor; tek araçla ilerlemek mümkün hâle geliyor, ama tabii her ekip hemen sarılır mı, orası ayrı konu.

Hmm, bunu nasıl anlatsamdı…

Evet.

Layer bazlı hook’lar, regülasyon yoğun sektörlerde change management süreçlerini azd‘ye taşımayı mümkün kılıyor. Bu küçük bir teknik özellik değil, mimarı bir kapı.

Hani bazen “bu da ne işe yarayacak” dediğimiz şeyler ölür ya, işte bu tam öyle başlamıyor aslında; sonra bir bakıyorsunuz onay akışını ayırmak, deployment sınırlarını netleştirmek ve ekipleri birbirine karıştırmadan ilerlemek kolaylaşıyor. Neyse uzatmayalım, özellikle kurumsal yapılarda böyle küçük görünen detaylar işi ciddi biçimde toparlıyor.

AI Model Quota Preflight: Hayatımı Kurtaracak

Yanı, Geçen ay bir müşteride OpenAI gpt-4o deployment’ı için provision başlattık, 18 dakika sonra da “quota yetersiz” diye yüzümüze patladı. 18 dakika! İnsan sınır oluyor, açık konuşayım. Şimdi azd, provision daha başlamadan model quota’sına bakıyor; yanı işin başında sana şunu söylüyor: “Abi, Sweden Central’da 50K TPM kalmış, bu şablon 100K istiyor, önce önü hallet.” Kısacası, sonradan tokat yemiyorsun.

Bu kısım AI yüklerinde baya kritik, hani sadece teknik bir detay gıbı duruyor ama öyle değil. Cosmos DB Maliyet Optimizasyonu: AI Yüklerinde 7 Taktık yazımda da değinmiştim; AI projelerinde quota yönetimi, maliyet kadar can sıkabiliyor (ben de ilk duyduğumda şaşırmıştım). Hatta bazen daha fazla. Preflight check tek başına azd‘ye geçmek için yeterli sebep gıbı duruyor, şey, en azından benim gözümde öyle.

Bir dakika — bununla bitmedi.

azd update Public Preview’da

Eskiden azd‘yi güncellemek için her platformda ayrı bir yol izliyorduk. Windows’ta MSI indir, Linux’ta install script’i yeniden çalıştır, Maç’te brew upgrade de geç. Iş biraz dağılıyordu. Şimdi işe her yerde aynı komut var:

azd update

İşin hoş tarafı da bu. Kağıt üstünde minicik bir detay gıbı duruyor, ama CI/CD pipeline’larında azd‘yi güncel tutmaya çalışan ekipler için baya rahatlatıyor. Bizim DevOps tarafında bunun için yaklaşık 30 satırlık bir script vardı, açık konuşayım, artık pek hükmü kalmadı.

Evet.

Peki neden önemli? Çünkü araç güncellemesi dediğin şey bazen “sonra bakarız” diye öteleniyor ve tam o sırada eski sürüm yüzünden garip bir hata çıkıyor (özellikle otomasyon tarafında, insanın canını sıkan türden). Burada tek komutla işi toparlamak fena değil, hatta çoğu senaryoda yeterince pratik.

Neyse uzatmayalım, küçük görünen ama günlük kullanımda iş gören bir yenilik bu. Siz de azd kullanan taraftaysanız, bu komutu bir kenara not edin; sonra lazım olunca arayıp durmazsınız.

Güvenlik Tarafında Sessiz Düzeltmeler

Bu ay iki tane güvenlik düzeltmesi var. Küçük görünüyorlar, ama öyle hafife alınacak şeyler değil.

• Windows MSI code-signing verification: Artık azd update ile gelen MSI paketinin imzası doğrulanıyor. Yanı araya bir şey girmiş mi, paketle oynanmış mı, bu tarafta ekstra bir kontrol devreye giriyor; supply chain tarafında işin rengi biraz daha güvenli tarafa kayıyor.
• Environment variable leak fix: Extension komutlarında bazı durumlarda env değişkenlerinin loglara sızdığı bir bug varmış, kapatılmış. Eğer extension kullanıyorsanız genelde güncelleyin.

Açık konuşayım, ben de zamanında güvenlik patch’lerini bazen “bir ara bakarım” diye ittiriyordum. Peki bunu neden söylüyorum? Sonra son bir yılda npm ekosisteminde olan bitenleri görünce fikir değişti; mesela Axios npm Saldırısı: Azure Pipelines Kullananlar İçin Rehber yazısında anlattığım olay da buna iyi bir örnekti, yanı mesele sadece tek bir paket değil, bütün zincirin açıkta kalabilmesi.

Neyse, çok uzattım. İşin aslı şu: tool’lar dahil her şeyi güncel tutmak lazım (buna dikkat edin)

Evet.

Custom Provisioning Providers: Extension Yazarları İçin

Şunu fark ettim: Bu özellik biraz niş, ama iş görüyor. Hani ne farkı var diyorsunuz, değil mi? Extension Framework içinde WithProvisioningProvider("name", factory) ile alternatif bir infrastructure backend kaydedebiliyorsunuz; sonra kullanıcı da azure.yaml içine infra: { provider: name } yazınca, sistem o sağlayıcıya dönüyor.

İtiraf edeyim, Aklıma ilk ne geliyor? Pulumi provider’ı, Crossplane provider’ı, hatta ekibin kendi Terraform wrapper’ı. Yanı azd‘nın developer experience tarafını alıp altına istediğiniz infra motorunu koyabiliyorsunuz, fena değil (ki bu çoğu kişinin gözünden kaçıyor). Şey ama, küçük bir not var: Extension Framework hâlâ Beta’da (azd‘nın kendisi GA olsa bile), o yüzden production tarafında biraz temkinli gitmek lazım bence. Bu konuyla ilgili VS 2026 Insiders 3’te TypeScript 7 Beta: 10x Hız Geldi yazımıza da göz atmanızı tavsiye ederim.

–no-prompt Davranışı Standartlaştı

CI/CD pipeline’larında, ya da AI agent senaryolarında, azd‘nın durup soru sorması açık konuşayım can sıkıyordu. Bazen --no-prompt bayrağı çalışıyor, bazen de bir anda “do you want to continue?” diye çıkıp akışı bozuyordu; şimdi bu davranış tüm komutlarda aynı hâle getirildi.

Peki neden? Bu konuyla ilgili Kubernetes v1.36 Controller Staleness: Artık Daha Az Acı yazımıza da göz atmanızı tavsiye ederim.

Bu iş özellikle Teams Agent Kurulumu: Prompt’tan Production’a Sade Yol yazımda anlattığım AI agent senaryolarında baya kritik. Mantıklı değil mi? Agent azd‘yi çağırıyor, sonra ortada interaktif prompt belirirse iş orada kilitleniyor, yanı sistem ilerlemiyor; şimdi bu taraf toparlandı ve akış daha temiz.

Türkiye Pratiği: Hangı Ekip Ne Yapmalı?

Şimdi asıl yere geldik. Sen ne yapmalısın? Ben müşterilerde gördüğüm tabloyu kabaca şöyle okuyorum, yanı ekip tipiyle beklentiyi eşleştirmek burada işin yarısı oluyor, yoksa herkes aynı aracı kullanıp sonra “neden böyle öldü” diye bakınıyor. Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşti yazımızda bu konuya da değinmiştik.

Profil	Tavsiyem	Öncelik
Startup / küçük ekip (Node ağırlıklı)	TypeScript hook’larına geç, tek dil tek tooling	Yüksek
Enterprise (.NET ağırlıklı)	.NET hook’ları + per-layer ile change management	Yüksek
AI / ML projeleri	Quota preflight için hemen güncelle, Python hook’ları	Çok yüksek
Regüle sektör (banka, sigorta)	Per-layer hooks ile katman bazlı onay süreci kur	Orta — pilot proje ile başla
Henüz azd kullanmayan	Önce küçük bir projede dene, ezbere geçirme	Düşük

Küçük ekiplerde iş daha net, açık konuşayım (inanın bana). Node tarafı baskınsa TypeScript hook’ları baya iş görüyor; tek dil, tek akış, daha az sürpriz. Ama dür bir saniye — bu otomatik olarak “her şeyi buna taşı” demek değil, çünkü ekipteki alışkanlıklar bazen araçtan daha belirleyici oluyor. Bu konuyla ilgili Kubernetes v1.36’da User Namespaces GA: Rootless Devri Geldi yazımıza da göz atmanızı tavsiye ederim.

Kurumsal tarafta işe hikâye biraz başka..NET ağırlıklı yapılarda.NET hook’larıyla per-layer yaklaşımı eklemek mantıklı geliyor,. Change management tarafında katman katman ilerlemek çoğu zaman daha az baş ağrısı yaratıyor; yine de bu işin sihri yok, sadece kontrol hissi biraz artıyor.

Evet.

AI ve ML projelerinde işe ben beklemeyi pek sevmem. Quota preflight kısmını hemen güncellemek lazım, Python hook’ları da burada fena değil; çünkü kaynak tüketimi bir anda zıplayabiliyor. Sonradan “aa kota dolmuş” demek pek tatlı ölmüyor. Siz de yaşadınız mı hiç?

Şunu söyleyeyim, Regüle sektörlerde işler doğal olarak daha yavaş akıyor. Banka ya da sigorta gıbı yerlerde per-layer hooks ile katman bazlı onay süreci kurmak daha güvenli hissettiriyor, (yanlış duymadınız). Burada da önce küçük bir pilot açmak şart gıbı; yoksa bütün organizasyonu bir anda yeni düzene sokmaya çalışınca ortalık karışabiliyor.

Ama şunu da söyleyeyim: Türkiye’de azd‘nın yayılımı biraz temkinli gidiyor. Birçok büyük şirket hâlâ Terraform veya raw Bicep ile devam ediyor ve azd‘yi çoğu zaman “tek developer şablonu” gıbı görüyorlar; halbuki multi-language hooks ve custom providers tarafı açılınca tablo değişiyor, sadece bunu herkes hemen fark etmiyor (en azından benim deneyimim böyle)

Bilmem anlatabiliyor muyum, Neyse uzatmayalım. Benim görüşüm şu: pilot proje yapmadan tüm — en azından ben öyle düşünüyorum — organizasyonu buna geçirmek biraz acele ölür (kendi tecrübem). Önce küçük bir yerde dene, sonra karar ver; işin aslı çoğu teknoloji tartışması burada çözülüyor zaten.

Karşılaştığım Bir Hata ve Çözümü

Bunu yaşayan biri olarak söyleyeyim, 1.24.0’a geçince, bir projede TypeScript hook tarafında npx tsx bulunamadı hatasıyla karşılaştım. İlk anda insanın aklına başka şeyler geliyor, hani “yeni özellik mi bozuldu acaba?” diye düşünüyorsun. Sonra baktım, işin aslı biraz daha basit: proje root’unda package.json vardı ama tsx bağımlılığı tanımlı değildi; azd npm install‘ı çalıştırıyor, fakat tsx yerelde olmayınca npx tsx‘i internetten çekmeye kalkıyor (corporate network’te proxy devreye girince de patlıyor), yanı zincirin kırıldığı yer tam burasıydı.

İnanın, Çözüm: devDependencies‘e tsx‘i ekledim, olay kapandı (bizzat test ettim). Evet, bu kadar. Eğer corporate proxy arkasındaysanız, bunu atlamayın; yoksa aynı hata size de göz kırpar, sonra uğraş dür.

İlk Adım Olarak Ne Yapın?

1. azd version ile elinizdeki sürümü bir kontrol edin
2. azd update ile en güncel sürüme çıkın (1.24.2)
3. Var olan bir Bash/PowerShell hook’unuzu alın, ekibin konuştuğu dile çevirin
4. Küçük bir test projesinde --layer flag’ını kurcalayın
5. AI projeleriniz varsa quota preflight’ın gerçekten çalıştığını doğrulayın

Açık konuşayım, azd artık sadece “demo aracı” gıbı durmuyor. Hani eskiden öyleydi biraz. Ama şimdi iş değişiyor, yavaş yavaş ciddiye binmeye başladı.

Hâlâ tam oturdu mu? Pek sayılmaz. En çok da Extension Framework tarafı biraz ham kalıyor, yanı orada insanın kaşı kalkıyor. Yön fena değil, hız da idare eder, bu yüzden ben buraya boşuna yatırım yapılacağını düşünmüyorum.

Bence önümüzdeki 6 ayda kurumsal kullanım belirgin biçimde artacak. Şaşırmam açıkçası. Çünkü ekipler bir kez akışı oturtunca, geri dönmek istemiyorlar; hele o hook işleri ve layer yaklaşımı biraz rayına girince, olay baya iş görüyor.

Evet.

Sıkça Sorulan Sorular

azd hook’larını Bash’ten Python’a yavaş yavaş taşıyabilir mıyım?

Evet, tabii ki. azure.yaml‘daki her hook bağımsız çalışıyor,. Birini Python’a çevirirken diğerleri Bash’te kalmaya devam edebilir. Ben de aslında böyle yaptım — önce kritik olanları taşıdım, basit logging hook’larını işe sona bıraktım.

Per-layer hook’lar production’da sorun çıkarır mı?

1.24.0 ile geliyor ve şimdiye kadar ciddi bir issue görmedim açıkçası (evet, doğru duydunuz). Yine de production’a almadan önce dev/staging ortamında en az 2 hafta çalıştırmanızı öneririm. Bilhassa complex Bicep modülleri olan projelerde layer dependency’leri iyi test edilmeli — bence bu kısmı atlamamak lazım.

Peki neden?

Custom provisioning provider yazmak ne kadar uğraştırıcı?

Doğruyu söylemek gerekirse, hiç kolay değil. Extension Framework hâlâ Beta’da ve dokümantasyon oldukça eksik. Ekibinizde Go bilen bir DevOps engineer varsa. Gerçekten alternatif bir infra backend’e ihtiyacınız varsa mantıklı olabilir. Yoksa bence beklemek daha akıllıca — GA olunca tekrar değerlendirirsiniz.

azd update her platformda çalışıyor mu?

Public preview’da ve Windows, Linux, macOS’ta çalışıyor. Ama hani public preview olduğu için zaman zaman edge case’lerde ufak sorunlar çıkabiliyor (kendi tecrübem). Tecrübeme göre manuel güncelleme yöntemini de bilmekte fayda var — her ihtimale karşı.

AI quota preflight tüm modellerde işe yarıyor mu?

Şu an için Azure OpenAI’daki temel modellerde çalışıyor — mesela gpt-4o, gpt-4, embedding modelleri gıbı. Üçüncü parti model deployment’ları ya da custom fine-tuned modeller için henüz tam destek gelmiş değil. Sürüm notlarında “AI model quota” başlığını takipte tutun, yakında genişleyeceğini düşünüyorum.

Kaynaklar ve İleri Okuma

Bakın, Azure Developer CLI (azd) – April 2026 Resmî Duyurusu

Azure Developer CLI Resmî Dokümantasyonu

azure-dev GitHub Reposu (Issues ve Discussions)

azd Hooks Artık Python, JS, TS ve.NET Destekliyor — multi-language hook’lar konusunda daha derin bir teknik inceleme (kendi tecrübem)