azd 1.26 Geldi: tool, exec ve Multi-Layer Provisioning Notları
Bir geliştirici aracının iki ayda dokuz sürüm çıkarması, açık konuşayım, insanda hafif bir “dur bakalım” hissi bırakıyor. Acele mi ediliyor? diye sormadan olmuyor. Ama Azure Developer CLI (azd) tarafında Mayıs-Haziran 2026 dönemine bakınca, gelen değişikliklerin çoğu tam da sahada uzun süredir “ya bu neden hâlâ böyle?” dediğimiz yerlere dokunuyor; yanı hız var ama boş hız değil, baya iş görüyor.
Lafı fazla dolandırmadan gireyim. Bu yazıda 1.24.3’ten 1.26.0’a kadar olan dönemde gözüme çarpan üç ana konu var: yeni azd tool komut grubu, azd exec,. Provisioning tarafındaki güvenlik ağı iyileştirmeleri. Geri kalanlar mı? Onları da topluca geçeceğim. Bazılarını “ha, bu da gelmiş” diye not düşeceğim — yoksa konu dağılıyor, sonra toparlamak zor oluyor.
Önemli not: Bu sürümler güvenlik iyileştirmeleri de içeriyor.
azd upgradekomutuyla en son sürüme geçmek artık opsiyonel değil, mecburiyet sınıfında.
azd tool: “Önce şunu kur, sonra şunu kur” çilesi bitiyor mu?
Araya gireyim: Yeni bir geliştiriciye azd template’i tanıttığınızı düşünün (inanın bana). Adam azd up diyor. Bicep CLI yok. Kısacası, kuruyor. Tekrar deniyor. Docker yok. Kuruyor. Sonra GitHub CLI sürümü eski çıkıyor, bir tür daha dönüyor, ve üç saat sonra ekibe Slack’ten “ben sanırım yanlış meslek seçtim” mesajı atıyor. Klasik.
İşte azd tool komut grubu tam olarak bu koşturmacayı azaltmak için geliyor. Artık şunları yapabiliyorsunuz:
azd tool list— template’in istediği araçları listeliyorazd tool install— eksik olanları otomatik kuruyor (bu kritik)azd tool check— her şey güncel mi diye bakıyor (artık paket yöneticilerini, extension registry’lerini ve VS Code Marketplace’i gerçekten sorguluyor, cache’e bakıp geçmiyor)azd tool upgrade— toplu yükseltme yapıyor — ciddi fark yaratıyor
Burada hoşuma giden ayrıntı şu: ilk kullanımda azd, bir “welcome” akışıyla önerilen araçları gösteriyor. Yanı yeni başlayan biri azd up komutunu çalıştırmadan önce, eksik bir prerequisite yüzünden duvara toslamadan önce uyarılıyor. 1.26’da bu komut grubu artık alpha’dan çıktı, varsayılan olarak açık. Güzel tarafı bu; ama dur bir saniye — biraz da geç kalmış gibi hissediyorum, çünkü böyle bir şeyin yıllar önce gelmesini beklerdim.
Hani, Evet.
Bir de azd tool install azure-skills diye yeni bir şey var — agentic CLI host’ları için per-host seçimle çalışıyor. Bunu henüz ciddi ciddi test etmedim, açık konuşayım, ama Copilot CLI. Benzeri ortamlarla iç içe geçen bir yapı kuruyor gibi dürüyor; yanı iş görüyor olabilir, ama sahada kaç ekip bunu gerçekten kullanır, orası biraz muamma. Bu konunun detayına merak edenler için
Peki neden?
Container Apps ve ACR Concurrency Düzeltmeleri
Eh, Paralel Container Apps deploy’larında bir bug vardı, açık konuşayım ben birebir yaşamadım. Community tarafında baya konuşulmuştu: ACR üstünde remote build çalışırken, birden fazla servisin image’i birbirine karışabiliyordu (cross-service image contamination). Yanı A servisi için üretilen image, race condition denk gelirse B servisinin tag’iyle push edilebiliyordu. Kulağa ufak geliyor ama değil.
Kısacası, açık konuşayım, Bu konu Mayıs-Haziran döneminde düzeltildi. Eğer microservices yapısında birden fazla container app’i tek bir azd up ile ayağa kaldırıyorsanız, bence 1.26’ya geçmekte gecikmeyin. Aşağıda kısa bir karşılaştırma var; hani tabloyu görünce fark daha net oturuyor, çünkü bazı şeyler kağıt üstünde küçük dürüyor ama pratikte can sıkıyor (inanın bana)
| Özellik / Senaryo | 1.24 ve öncesi | 1.26.0 |
|---|---|---|
| Tool prerequisite check | Manuel, dağınık | azd tool komut grubu |
| Script + Key Vault context | Manuel export | azd exec |
| Multi-layer dependency | Implicit, kırılgan | Explicit dependsOn |
| Ctrl+C davranışı | Belirsiz | Interactive prompt |
| ACR remote build (paralel) | Image contamination riski | Düzeltildi |
| Go + Azure Functions | Yok | azd up destekliyor |
| Extension dağıtımı | Registry zorunlu | Self-contained bundle |
Bakın, neyse, çok dağıtmadan söyleyeyim: bu tip concurrency sorunları genelde gözden kaçar, sonra da “neden yanlış image geldi?” diye insanı uğraştırır. İşin aslı burada kritik nokta şu; aynı anda çalışan build süreçleri izolasyon beklediğiniz kadar temiz değilse, sonuç garipleşiyor. Sız ne dersiniz?
Evet, doğru duydunuz.
Dürüst olmak gerekirse, Evet.
Bana kalırsa 1.26 tarafı sadece bu düzeltme yüzünden bile daha rahat hissettiriyor. Üstelik azd tool, azd exec, açık dependsOn, Ctrl+C prompt’u gibi küçük görünen şeyler de günlük akışta baya iş görüyor; hani tek başına devrim değil ama topluca bakınca eli yüzü düzgün bir sürüm olmuş.
Peki neden önemli? Çünkü microservices tarafında deploy zinciri uzadıkça, bir yerde belirsizlik çıkınca önü takip etmek zorlaşıyor. Bu yüzden ben — kendi adıma konuşayım — olsam, özellikle tek komutla çoklu app deploy eden ekiplerde, önce sürümü kontrol ederim; sonra da remote build akışını sessizce test ederim. Tam da öyle.
Bunu biraz açayım.
Go for Azure Functions, Extension Bundles ve Subscription Filter
Hızlı geçiyorum, çünkü yazı zaten epey uzadı. Üç küçük ama iş gören detay daha var:
Go dili artık Azure Functions tarafında azd up ile destekleniyor (kendi tecrübem). Go ile serverless iş yapanlar — Türkiye’de sayısı çok da uçuk değil, ama yine de belli bir kitle var — artık tam azd akışına rahatça girebilir. Bilhassa veri pipeline’larında ve küçük event-driven servislerde baya işe yarıyor.
Self-contained extension bundles: Eskiden azd extension paylaşmak için bir registry’e push etmeniz gerekiyordu. Şirket içinde yazdığınız bir extension’ı sadece ekiple paylaşmak istiyorsanız, kendi registry’nızı ayağa kaldırmanız şarttı; açık konuşayım, bu biraz uğraştırıyordu. Artık öyle değil — bundle olarak paketleyip dosya gibi dağıtabiliyorsunuz. Bunu kurumsal tarafta baya kullanışlı buluyorum, özellikle compliance yüzünden “dışarı paket yayınlama” yasağı olan finans. Kamu senaryolarında.
Ne yalan söyleyeyim, Per-tenant subscription filters: Birden fazla tenant’ta çalışıyorsanız (danışmanlık yapanlar, MSP’ler, ortak hizmet veren yapılar), azd her seferinde önünüze 50-100 subscription diziyordu, sonra sız de orada biraz debeleniyordunuz. Şimdi seçtiğiniz filtre tenant bazında saklanıyor. Küçük bir detay gibi dürüyor, ama insanı gereksiz tekrar işten kurtarıyor.
Evet.
Neyse uzatmayayım, bunlar tek başına manşetlik şeyler değil belki. Ama günlük kullanımda fark ettiriyorlar; hele ki Azure tarafında sürekli aynı döngüye giren biriyseniz, bu tip minik iyileştirmeler gerçekten can sıkıntısını azaltıyor.
Pratik geçiş rehberi: ne yapmalısınız?
Eğer azd zaten kullanıyorsanız, bence çok kasmadan şu sırayla gidin. azd version ile önce elinizde ne var görün, çünkü bazen ortamda bir şeyler dönüyor. Insan tam sürümü unutuyor; sonra azd upgrade ile 1.26.0’a geçin (güvenlik yamaları da var, yanı bunu öyle “sonra bakarım” diye bırakmayın).
azd versionile mevcut sürümünüzü kontrol edinazd upgradeile 1.26.0’a geçin (güvenlik yamaları var, ertelemeyin)- Mevcut
azure.yamldosyalarınızdaki servis bağımlılıklarını gözden geçirip explicitdependsOnekleyin — özellikle multi-service projeleriniz varsa - CI pipeline’larınızda secret çekmek için karma script’leriniz varsa,
azd execile sadeleştirmeyi deneyin (önce dev branch’te test edin tabi) - Yeni gelen ekip üyeleri için onboarding dokümanınızı güncelleyin — artık tek satır:
azd tool listveazd tool install
Vallahi, Peki neden? Çünkü multi-service tarafta iş biraz sessizce dağılıyor, sonra bir bakıyorsunuz servislerden biri diğerini beklemiyor. Debug oturumu uzuyor; bu yüzden azure.yaml içinde bağımlılıkları açık açık yazmak baya iş görüyor, hele ki proje büyüdüyse.
Araya gireyim: Açık konuşayım, CI tarafında da aynı hikâye var. Eğer secret çekmek için her pipeline’da ayrı ayrı script dönduruyorsanız, biraz yorucu oluyor; azd exec ile sadeleştirmek çoğu zaman daha temiz dürüyor, ama önce dev branch’te denemek lazım tabiî, yoksa insan sonradan “keşke” diyor.
Neyse, onboarding kısmını da hafife almayın. Yeni gelen biri için iki komut yeterince net: azd tool list. azd tool install; gerisi zaten pratikte oturuyor.
İşin garibi, Tam da öyle.
İşin garibi, Evet.
Lafı gevelemeden: azd kullanıyorsanız 1.26.0’a çıkın, bağımlılıkları netleştirin, script kalabalığını azaltın. Dokümanı sade tutun. Bu kadar mı? Aslında evet, çoğu ekip için işin omurgası bu kadar basit kalıyor.
Benim genel kanaatim: iyi gidiyor ama eksikler var
Açık konuşayım. azd’yi 2022’den beri izliyorum. Ilk zamanlardaki o “deneyeyim bakalım” hissi, yavaş yavaş yerini daha ciddi bir DX (developer experience) aracına bıraktı. Tahmin eder mısınız? azd tool ve azd exec bence baya iş görüyor, hatta bazı işlerde insanın elini rahatlatıyor; ama dur bir saniye — eksik tarafları da yok değil.
Birincisi, Terraform desteği hâlâ Bicep’in biraz gerisinde kalıyor. Türkiye’de görüştüğüm bazı kurumsal ekipler “biz — itiraz edebilirsiniz tabi — Bicep’e fazla bağlanmak istemiyoruz” diyor, haklılar da; hani herkesin standardı aynı değil. azd burada daha cesur davranabilirdi, çünkü bu alan biraz açılırsa araç daha çok yere dokunur.
Tuhaf ama, İkincisi, hata mesajları bazen hâlâ şifre gibi geliyor (bu konuda ikircikliyim). “Provisioning failed” deyip altına Azure Resource — ki bu tartışılır — Manager hatasını olduğu gibi döşeyince, geliştirici tarafında pek sıcak bir karşılama olmuyor; yanı teknik olarak bilgi veriyor ama kullanıcıyı tutup kolundan çekmiyor. Bu konuda ilerleme var, evet, fakat “gel büyür seninleyim” hissi henüz tam oturmamış.
Tuhaf ama, Üçüncüsü — bu biraz sertifika kafasıyla ilgili olabilir, şey — security posture varsayılanları daha sıkı olabilirdi. Yeni açılan kaynaklarda private endpoint, managed identity ve RBAC gibi başlıklar çoğu zaman template’e bırakılıyor; azd’nın kendi içinde biraz daha “secure by default” yaklaşımı koyması fena olmazdı. AZ-500 tarafından bakınca ben bu boşluğu net hissediyorum.
Kısa bir not düşeyim buraya.
İnanın, Yine de toplam tabloya bakınca puanım yüksek. Bu sürüm trenine binilir, açık söyleyeyim. Cloud operations tarafının nereye kaydığını merak edenler için Agentic Cloud Operations: İçgörüden Eyleme Geçen Bulut Devri yazım da iyi bir eşlikçi olur.
Sıkça Sorulan Sorular
azd ile Terraform kullanabilir mıyım, yoksa illâ Bicep mi gerekiyor?
Terraform desteği var, ama açıkçası Bicep kadar olgun değil. Eğer ekibiniz Terraform’a ciddi yatırım yapmışsa azd’nın Terraform provider’ını kullanabilirsiniz — (en azından benim deneyimim böyle). Tamamen kapı dışı değil. Ama şunu söyleyeyim: yeni özellikler (mesela multi-layer dependsOn analizi gibi şeyler) önce Bicep tarafında çıkıyor, sonra Terraform’a yansıyor. İlginç, değil mi? Bence kararlı bir deneyim istiyorsanız bir sürüm geriden takip etmek mantıklı.
azd exec ile çalıştırdığım script Key Vault secret’larına nasıl erişiyor?
azd, environment context’ını child process’e miras bırakıyor ve Key Vault referanslarını çalışma anında çözümlüyor. Yanı azure.yaml içinde Key Vault’a referans verdiğiniz bir environment variable, script’inizde aslında normal bir env var gibi okunabiliyor (en azından benim deneyimim böyle). Manuel az keyvault secret — ki bu tartışılır — show çağrısına gerek kalmıyor — kimlik doğrulama için zaten azd’nın oturum açtığı kimlik kullanılıyor. Tecrübeme göre bu kısmı bir kez anlayınca işler çok kolaylaşıyor.
Hmm, bunu nasıl anlatsamdı…
1.26’ya geçmek breaking change içeriyor mu?
Büyük bir breaking change yok. Ama azd tool komut grubunun alpha’dan default’a alınması bazı CI script’lerinde davranış değişikliğine yol açabiliyor — hani fark etmeden geçiverirsiniz, dikkat edin. Bir de güvenlik — en azından ben öyle düşünüyorum — düzeltmeleri var, yanı sürüm pinning yapan ekiplerin minimum sürümü güncellemesi gerekiyor. Bence production pipeline’larında önce staging’de test edin, sonra geçin (yanlış duymadınız)
Self-contained extension bundle nasıl paylaşılır?
Extension’ınızı bundle olarak paketledikten sonra çıkan dosyayı SharePoint, internal Git repo veya artifact storage gibi bir yerde paylaşabilirsiniz. Kullanıcılar da lokalden azd extension install komutuyla yükleyebiliyor. Kurumsal compliance açısından bakınca bu aslında güzel bir avantaj — yanı public registry’e bağımlı olmuyorsunuz.
Hmm, bunu nasıl anlatsamdı…
Go ile yazılmış Azure Functions için azd up gerçekten production-ready mi?
Bence, Genel akış çalışıyor, ama ekosistem hâlâ JavaScript/TypeScript ve C# tarafı kadar olgun değil açıkçası. Build ve packaging adımları stabil. Ancak monitöring entegrasyonu, custom handler senaryoları gibi konularda dokümantasyon biraz ince kalıyor. Production’a almadan önce büyük ihtimalle bir POC ile deneyin — özellikle cold start davranışını kendi yükünüzle test etmenizi tavsiye ederim.
Kaynaklar ve İleri Okuma
Azure Developer CLI (azd) – May and June 2026 (Microsoft DevBlogs)
Azure Developer CLI Resmî Dokümantasyonu
azd GitHub Releases — Tüm sürüm notları. PR linkleri
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