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.
📋 İçindekiler
-
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
azdkomutu çalıştığında tetikleniyor. Yanıazd updediğ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ındanpm installkoş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 installiletsxayağ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
requestsyetiyor olabilir.💡 Bilgi: Azure DevOps pipeline’larında azd hook’ları kullanıyorsanız, Microsoft-hosted agent’larda Python, Node.js ve.NET zaten yüklü geliyor. Ama self-hosted agent kullanıyorsanız bu runtime’ları kendiniz kurmanız gerekir. Bunu atlayan çok ekip gördüm.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.
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
kindalanıyla dili kendiniz belirtebilirsiniz.TypeScript hook’ları için tsconfig.json gerekiyor mu?
Hayır, gerekmiyor. azd TypeScript dosyalarını
npx tsxile ç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. Tabiî 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
Aslı S.
Sonunda bu özellik geldi, Bash’te hook yazmak bazen gerçekten can sıkıcı oluyordu. TypeScript ile yazabilmek özellikle frontend ağırlıklı ekipler için büyük kolaylık olacak, hemen deneyeceğim.
Oğuz L.
Bash yazmak zorunda kalmadan Python ile hook yazabilmek gerçekten güzel bir gelişme, özellikle ekipte shell bilmeyen arkadaşlar için can kurtarıcı olacak. .NET desteği de eklenince artık hiçbir bahane kalmıyor sanırım.
Serkan D.
Bash’te environment variable kontrolü yazmak her seferinde biraz eziyete dönüyordu, Python desteği gerçekten işe yarayacak. Peki mevcut hook’ları migrate etmek için özel bir araç var mı yoksa elle mi taşımak gerekiyor?
Yorumlar kapalı.







3 comments