azd Hook’larını Python, TypeScript, .NET ile Yazın

Şahsen, Geçen hafta bir müşteride, finans tarafında çalışan epey kalabalık bir ekiple, azd ile deployment pipeline’ı kuruyorduk (ben de ilk duyduğumda şaşırmıştım). Hook yazma kısmına gelince ekipteki Python geliştiricisi bir anda durdu ve, “Ben Bash bilmiyorum, bu hook’u nasıl yazacağım?” dedi. Haklıydı. Adam bütün gün Python yazıyor, sonra tek bir hook için Bash öğrenmeye kalkıyor; açık konuşayım, bu iş biraz ters dürüyor.

İşte mesele tam burada başlıyor. Azure Developer CLI artık hook’ları Python, JavaScript, TypeScript ve.NET ile yazmanıza izin veriyor. Yanı Bash ve PowerShell’e mecbur değilsiniz. Basit gibi görünüyor,. Dur bir saniye — günlük geliştirici akışında bunun etkisi bayağı hissediliyor, çünkü ekipler kendi bildikleri dille ilerleyince iş daha az takılıyor.

Hook Nedir ve Neden Bu Kadar Önemli?

Bilmeyenler için kısa söyleyeyim: azd hook’ları, Azure Developer CLI’ın yaşam döngüsündeki belli noktalarda çalışan küçük script’ler. Mesela provisioning başlamadan önce ortamı bir yoklamak istiyorsunuz, ya da deployment bittikten sonra veritabanına seed data basmak istiyorsunuz; işte hook’lar tam burada devreye giriyor. Basit dürüyor, ama değil.

Önceden sadece Bash ve PowerShell vardı. Yanı ister Python yazın, ister TypeScript tarafında olun, hook yazmak için shell scripting’e bulaşmanız gerekiyordu (evet, doğru duydunuz). Açık konuşayım, birçok ekip burada frene basıyordu; “boşver sonra bakarız” deniyordu çünkü kimse o script karmaşasıyla uğraşmak istemiyordu. Sonuçta manuel adımlar çıkıyor, konfigürasyonlar unutuluyor, deployment sonrası da biri dönüp “aa bunu yapmayı atlamışız” diyor. Can sıkıcı.

2022’de kendi projelerimden birinde preprovision hook’ünü PowerShell ile yazmıştım. Basit bir Azure Key Vault kontrolü yapıyordu ama script bir anda 80 satıra uzamıştı; hani işin özü üç beş kontroldü aslında, fakat PowerShell tarafında o kadar dolanmıştı ki gözüm korkmuştu. Aynı şeyi Python ile muhtemelen 15 satırda çıkarırdım. Ciddi söylüyorum, 15 satır. Evet.

Yeni Dil Desteği Nasıl Çalışıyor?

Şunu fark ettim: Işin güzel tarafı su: neredeyse ekstra bir konfigürasyon yapmiyorsunuz. azd, dosya uzantısına bakıp dili kendi buluyor; yanı .py görünce Python, .ts görünce TypeScript, .cs görünce de.NET gibi davranıp scripti çalıştırıyor. Kısa ve net. Hatta ilk gördüğümde “bu kadar mi?” dedim.

Bir dakika — bununla bitmedi.

Ama dur bir saniye — bazen uzantı ortada yok, bazen de dosya uzantisiz geliyor. O noktada işi garantiye almak için kind alanını açıkça veriyorsunuz, böylece azd neyi nasıl çalıştıracağını tahmin etmeye çalışmıyor:

# azure.yaml
hooks:
preprovision:
run:./hooks/setup.py
postdeploy:
run:./hooks/seed.ts
postprovision:
run:./hooks/migrate.cs

Şahsen, Eğer uzantı belirsizse is değişiyor:

hooks:
preprovision:
run:./hooks/setup
kind: python # acikca belirtiyorsunuz

Her dil için azd’nın arkada yaptığı şey biraz farklı. Tabloya dökeyim dedim, çünkü yaziyla anlatınca insanın kafası ufak ufak karışabiliyor. Bir de şöyle — ki bu tartışılır — bir durum var: aynı akışın içinde benzer gorunuyorlar. Alt tarafta işleyen mekanizma pek öyle tek kalıp değil.

Neyse, konu aslında burada basit. Azd, uzantidan anliyorsa hiç uğraştırmıyor; anlamiyorsa sız devreye giriyorsunuz. Bence idare eder bir denge kurmuslar.

Çok konuştum, örnekle göstereyim.

İşte, peki neden? Çünkü hook tarafında hızlı geçmek istiyorsanız her seferinde ayrı ayrı komut yazmak can sıkabiliyor. Bu yöntem biraz pratiklik sağlıyor,. Tabi elinizde garip isimlendirilmiş dosyalar varsa bir noktada kind ile netleştirmek daha mantıklı oluyor.

Python Hook’ları: Detaylı Bakış

Python geliştiriyorsanız, bu bölüm tam size göre. Hook dosyanızın yanına bir requirements.txt bırakıyorsunuz, azd de gerisini toparlıyor; sanal ortamı açıyor, bağımlılıkları kuruyor, scripti koşturuyor (ciddiyim). Yanı işin omurgası sizde kalıyor, kalan kısım bayağı otomatik gidiyor.

hooks/
├── setup.py
└── requirements.txt

Güzel tarafı şu: azd sadece scriptin durduğu klasöre bakmıyor. requirements.txt orada yoksa bir üst dizine çıkıp aramaya devam ediyor, bu da monorepo kurulumlarında gerçekten işe yarıyor (özellikle tek kökten yönetilen projelerde). Logosoft’ta bir e-ticaret müşterimizde aynen böyle kullanmıştık — kök dizinde tek bir requirements.txt, altında da 5-6 ayrı hook scripti vardı; açık konuşayım, düzenliydi ve sorunsuz çalışıyordu.

Ama burada küçük bir ama var. Eğer hook scriptiniz pandas, numpy gibi biraz ağır paketlere yaslanıyorsa, ilk çalıştırmada bekleme görebilirsiniz; sanal ortam kuruluyor, paketler iniyor, sonra script ayağa kalkıyor. İkinci denemede cache devreye girdiği için işler hızlanıyor ama ilk seferde sabırlı olmak lazım. Evet, biraz can sıkıyor.

Türkiye’deki Ekipler İçin Pratik Bir Not

Türkiye’de çalıştığım ekiplerin çoğunda Python ana dil gibi kullanılıyor, özellikle veri mühendisliği ve backend tarafında. Bu yüzden azd hook’larının Python desteği baya iş görüyor. Ama şöyle bir gerçek de var: birçok ekip hâlâ azd yerine doğrudan Terraform ya da Bicep ile ilerliyor; hatta azd’nın adını duymamış olanlar bile çıkıyor. Sız de o gruptaysanız önce azd’ye bir bakın derim — hook’lar onun üstüne gelen güzel bir ek özellik gibi dürüyor, tek başına mesele değil yanı.

TypeScript ve JavaScript: Derleme Derdi Yok

Şöyle ki, TypeScript hook’larının en hoş tarafı şu: derleme adımıyla uğraşmıyorsunuz. azd, TypeScript dosyalarını doğrudan npx tsx ile çalıştırıyor; yanı ortada ekstra bir build süreci yok, tsconfig.json bile şart değil (evet, ilk duyunca ben de “nasıl yanı?” dedim). Açık konuşayım, bu kısım biraz şaşırtıcı geliyor ama işliyor.

Durun, bir saniye.

JavaScript tarafında da tablo pek değişmiyor. Bir package.json koyuyorsunuz, azd npm install yapıyor, sonra scripti koşturuyor. Farklı bir paket yöneticisi kullanıyorsanız da (yarn, pnpm gibi), bunu config içinden ayarlayabiliyorsunuz; yanı işler tamamen kilitlenmiyor, biraz esneklik var.

hooks/
├── seed.ts
└── package.json

Bunu yaşayan biri olarak söyleyeyim, Geçen ay bir startup’ta — 4 kişilik minicik bir ekipti — tam TypeScript stack kullanıyorlardı. Frontend Next.js, backend Node.js, hatta IaC tarafında Pulumi ile TypeScript gidiyorlardı; hook’ları da TypeScript ile yazınca proje neredeyse tek dile toplandı (bu arada context switching baya azaldı). Adam bana “artık projemde tek satır bile Bash yok” dedi, gülerek. Şey… haksız da sayılmazdı.

Küçük Ekip vs Enterprise: Fark Ne?

Küçük ekipseniz TypeScript hook’ları baya iş görüyor. Hızlısınız, dağıtmıyorsunuz, her şey aynı dilde akıyor; peki neden? Çünkü kafa sürekli başka bir sözdizimine zıplamıyor. Ama enterprise tarafına geçince iş biraz kıvrılıyor. Büyük kurumlarda DevOps ayrı takım oluyor, uygulama ekibi ayrı kalıyor. Biri Bash/PowerShell’e yatkınken diğeri TypeScript’te rahat ediyor; hook’ları kimin yazacağı da ister istemez küçük bir çekişmeye dönüyor.

Size bir şey söyleyeyim, Ben olsam ne yaparım? Açık söyleyeyim, hook’ları uygulama ekibine bırakırım. Onlar kendi dillerinde yazar, daha az sürtünme olur; DevOps ekibi de pipeline’a odaklanır (hani herkes kendi bildiği işi yapınca ortalık biraz daha sakinleşiyor). Az önce küçük ekipte iş kolay dedim ama burada asıl mesele hız değil, sahiplik ve bakım yükü (ben de ilk duyduğumda şaşırmıştım)

Çok konuştum, örnekle göstereyim.

.NET Hook’ları: İki Farklı Mod

Vallahi,.NET tarafında iş iki kola ayrılıyor, ve açık konuşayım bu ayrımı baştan netleştirmek iyi oluyor (en azından benim deneyimim böyle)

Proje modu: Scriptin yanında bir .csproj dosyası varsa, azd otomatik olarak dotnet restore ve dotnet build çalıştırıyor. Klasik.NET düzeni bu; biraz eski usül dürüyor ama oturmuş bir akış. NuGet paketleri kullanıyorsanız, ben olsam burada kalırım.

Tek dosya modu:.NET 10 ve üzerinde, tek bir .cs dosyasını doğrudan dotnet run script.cs ile çalıştırabiliyorsunuz. Proje dosyası yok. Bu özellik.NET 10 ile geldi ve hook senaryolarında baya iş görüyor, ama hani her yerde koşup gitmez; bazı yerlerde hâlâ proje yapısı daha rahat hissettiriyor.

hooks/
├── migrate.cs
└── migrate.csproj #.NET 10+ ise opsiyonel

💡.NET 10 tek dosya modu henüz çok yeni. Production’da kullanmadan önce kendi ortamınızda mutlaka test edin. Ben ilk denememde bir namespace çakışması yaşadım — çözümü basitti ama beklenmedik bir şeydi.

Evet, tam da burada küçük bir uyarı var.

Ha bu arada, .NET 10 Data Protection Güvenlik Açığı ve Acil Yama yazımda.NET 10 ile ilgili güvenlik konularını ele almıştım. Hook yazarken de güvenlik kısmını boş geçmeyin derim; özellikle hook’larınız Key Vault ya da secret erişimi yapıyorsa, işin aslı biraz daha hassaslaşıyor ve orada “nasıl olsa olur” demek pek iyi sonuç vermiyor. Bu konuyla ilgili Kubernetes’te Production Debug Güvenliği: Rehber yazımıza da göz atmanızı tavsiye ederim.

Ve işler burada ilginçleşiyor.

Bakın, peki neden? Cosmos DB Dynamic Data Masking: Veri Güvenliğinde Yeni Dönem yazımızda bu konuya da değinmiştik.

Maliyet ve Performans: Kimse Konuşmuyor Ama…

Herkes yeni özelliklere atlıyor da, performans tarafını pek kurcalamıyor (kendi tecrübem). Ben sorayım o zaman. Peki neden?

İşin garibi, Hook’lar her azd komutu çalıştığında tetikleniyor. Yanı azd up dediğiniz anda preprovision, postprovision, postdeploy hook’ları sırayla devreye giriyor; sonra da her birinin kendi bağımlılık hazırlığı başlıyor (Python için venv açılıyor, JavaScript tarafında npm install koşuyor, bazen de ufak ufak başka işler çıkıyor), işte tam burada süre uzuyor.

Bence, Kendi testlerimde şunu gördüm: basit bir Python hook’u ilk çalıştırmada yaklaşık 12 saniye sürüyor, sonraki çalıştırmalarda işe 2 saniye civarına düşüyor. TypeScript tarafı biraz daha ağır geliyor; ilk seferde 18 saniye civarı görüyorum (npm install ile tsx ayağa kalkana kadar bekliyorsunuz),.NET proje modunda işe build süresi projenin boyutuna göre değişiyor, yanı sabit bir sayı vermek zor.

Kısa bir not düşeyim buraya.

Enterprise CI/CD pipeline’ında bu süreler küçük görünse de can sıkabiliyor. Günde 50 deployment yapıyorsanız ve her deployment’a 30 saniye ekleniyorsa, ay sonunda ortaya saatler çıkıyor; açık konuşayım, ekip bunu ilk başta fark etmeyebiliyor ama fatura gelince tablo netleşiyor. Bütçe tarafı hassassa, hook bağımlılıklarını minimal tutun; mesela bir hook içine pandas koymayın, çoğu senaryoda sadece requests yetiyor olabilir.

Pratik Uygulama: Nereden Başlamalı?

Tamam, özellik netleşti. Peki yarın sabah ne yapacaksınız? (kendi tecrübem)

İlk iş, mevcut Bash ve PowerShell hook’larını tek tek açıp bakın; hangisi gerçekten işe yarıyor, hangisi sadece yıllardır orada dürüyor, önü ayıklayın (ben olsam önce en basit olanı seçerim), çünkü hepsini aynı anda çevirmeye kalkınca iş biraz dağılıyor ve gereksiz yere kafa karıştırıyor. Daha fazla bilgi için SQL Server 2025’te Güvenlik ve MCP: Tek Motor Yeter mi? yazımıza bakabilirsiniz.

Sonra azure.yaml dosyanıza girin ve hook tanımlarını güncelleyin. Dosya uzantısını değiştirmeniz çoğu zaman yetiyor, azd de bunu genelde kendi kendine yakalıyor. Basit gibi dürüyor.

Şahsen, Üçüncü adımda işi lokalde bırakmayın, CI/CD pipeline içinde de deneyin; çünkü yerelde çalışan bir hook, pipeline tarafında bambaşka bir sürpriz çıkarabiliyor (özellikle dosya yolları, ortam değişkenleri ve agent farkları yüzünden), yanı “bende çalıştı” cümlesi burada pek kurtarmıyor.

Bir de şu detay var: Azure SDK Nisan 2026: Kritik Güvenlik Yaması ve Yenilikler yazısında anlattığım SDK güncellemelerini hook’larınızda kullanıyorsanız, versiyon uyumluluğunu mutlaka kontrol edin; eski SDK sürümleri yeni azd hook sistemiyle bazen garip hatalar veriyor, hani “neden şimdi patladı?” dedirten cinsten.

Alternatif Yaklaşım: Bütçeniz Kısıtlıysa

Açıkçası, Eğer henüz azd’ye geçmediyseniz. Bütçe tarafı sıkışıkse, hook’ları doğrudan Azure DevOps pipeline task’ları olarak da yazabilirsiniz. Aynı esnekliği vermiyor, açık konuşayım; ama sıfır ek maliyetle ilerliyorsunuz (küçük projelerde bu tercih gayet idare eder), üstelik bazen sırf sadelik için daha mantıklı bile olabiliyor.

azd’nın hook sistemi daha düzenli geliyor bana, fakat “olmazsa olmaz” da değil. Hele bir de küçük ekiplerde önce çalışan çözümü kurup sonra iyileştirmek daha sağlıklı oluyor (eh, fena değil). Azure DevOps Server Nisan Yaması: Ne Geldi, Ne Yapmalı? yazısında DevOps tarafındaki güncel gelişmeleri bulabilirsiniz.

Beklentim vs Gerçeklik

Açık konuşayım: özellik fena değil, ama henüz tam oturmamış. Birkaç yerde insanın kaşı kalkıyor.

Birincisi, hata mesajları baya zayıf. Hook içinde bir Python hatası patlayınca azd’nın döndürdüğü şey çoğu zaman “hook failed with exit code 1” gibi kuru bir satır oluyor; alttaki Python traceback’ını görmek için verbose mode açmanız gerekiyor, yanı sorun aslında orada dürüyor. Size ilk anda gösterilmiyor. Yeni başlayan biriyseniz, bu durum biraz sınır bozucu, hatta gereksiz yere vakit yediriyor.

İkincisi, hook’lar arasında veri taşımak hâlâ uğraştırıyor. Preprovision hook’undan postprovision hook’una bir şey aktarmak istiyorsanız, ya ortam değişkenlerine yaslanıyorsunuz ya da dosya sistemiyle idare ediyorsunuz; iş görüyor. Pek zarif değil. Bence burada shared context objesi gibi daha temiz bir yol olabilirdi, çünkü şu anki yaklaşım biraz dolambaçlı kalıyor.

Üçüncüsü — ve açıkçası beni en çok burası düşündürdü — hot reload yok. Hook’u değiştirip yeniden çalıştırdığınızda sistem her seferinde bağımlılıkları tekrar kontrol ediyor; küçük bir deneme yapacaksınız, hop bekliyorsunuz. Geliştirme aşamasında bu gerçekten yavaşlatıyor, insanın hevesi de biraz kırılıyor.

Dürüst olmak gerekirse, Ama neyse, kağıt üstünde iyi bir adım bu. Pratikte işe biraz daha pişmesi lazım; şimdiye kadar gördüğüm kadarıyla birkaç versiyon sonra çok daha rahat kullanılacak hâle gelir diye düşünüyorum.

Sıkça Sorulan Sorular

azd hook’larında hangi diller destekleniyor?

Bash ve PowerShell’e ek olarak artık Python, JavaScript, TypeScript ve.NET de destekleniyor. azd dosya uzantısına bakarak dili otomatik algılıyor (şaşırtıcı ama gerçek). Yanı çoğu durumda ekstra bir şey yapmanıza gerek yok (buna dikkat edin). Ama belirsiz bir durum varsa azure.yaml içinde kind alanıyla dili kendiniz belirtebilirsiniz.

TypeScript hook’ları için tsconfig.json gerekiyor mu?

Hayır, gerekmiyor. azd TypeScript dosyalarını npx tsx ile çalıştırıyor — ayrıca derleme adımı falan yok, tsconfig.json da istenmiyor. Aslında sadece bir package.json yeterli, bu kadar.

.NET tek dosya modu hangi versiyondan itibaren çalışıyor?

.NET 10. Üzeri sürümlerde tek bir.cs dosyasını doğrudan çalıştırabiliyorsunuz, hani proje dosyasına bile gerek kalmıyor. Ama daha eski.NET sürümlerindeyseniz.csproj dosyası hâlâ gerekiyor.

Hook’lardaki bağımlılıklar her çalıştırmada yeniden mi kuruluyor?

İlk seferinde evet — sanal ortam oluşturuluyor, bağımlılıklar kuruluyor. Sonrasında cache devreye giriyor, dolayısıyla — itiraz edebilirsiniz tabi — çok daha hızlı ilerliyor. Tecrübeme göre bu farkı özellikle büyük projelerde gerçekten hissediyorsunuz. Tabii bağımlılık dosyası değişirse, mesela requirements.txt güncellediyseniz, yeniden kurulum yapılıyor.

Mevcut Bash hook’larımı hemen değiştirmeli mıyım?

Şöyle ki, Acil bir durum yok açıkçası — Bash ve PowerShell hook’ları sorunsuz çalışmaya devam ediyor (kendi tecrübem). Ama yeni bir hook yazacaksanız ya da mevcut olanları refactor edecekseniz, bence proje dilinize geçmek mantıklı. Hani sürekli dil değiştirmek zorunda kalmamak uzun vadede ciddi bir verimlilik artışı sağlıyor.

Kaynaklar ve İleri Okuma

Azure Developer CLI Extensibility — Resmî Dokümantasyon

Write azd hooks in Python, JavaScript, TypeScript, or.NET — Azure SDK Blog

Azure Developer CLI GitHub Repository

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

Azure Boards’ta Markdown Düzenleyici Neden Daha Sakin Oldu?5 Nis 2026

Azure ile Spring Testlerinde Docker Kullanınca Ne Değişiyor?1 Nis 2026

CodeQL Autofix Raporları Artık Daha Gerçekçi31 Mar 2026

SELinux Volume Label Değişikliği: v1.37 Öncesi Hazırlık23 Nis 2026