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 Copilot CLI’ın Yeni Terminal Arayüzü GA: Sekmeler Devri Basladı yazımda terminal tarafındaki gidişatı uzun uzun anlatmıştım.
Türkiye’deki ekipler için bu ne anlama geliyor?
Bakın, Açık konuşayım: Türkiye’de azd benimsenme oranı, ABD veya Batı Avrupa’ya göre baya geride. Sahada gördüğüm tablo şu; pek çok ekip hâlâ Bicep’i manuel az deployment komutlarıyla, GitHub Actions YAML’ında uğraşa uğraşa yönetiyor, sonra da “bu iş niye bu kadar karmaşık?” diye soruyor. azd işe “infra + app + pipeline” üçlüsünü tek çatı altında toparlamaya çalışıyor ama tabiî hemen karşısına şu itiraz çıkıyor: “Biz zaten Terraform kullanıyoruz” ya da “Bicep’ımız var, niye değiştirelim?” Haklılık payı var mı? Var. Ama bazen mesele değiştirmek değil, başlangıç sürtünmesini azaltmak oluyor.
Lafı gevelemeden söyleyeyim: azd tool gibi geliştirmeler tam da bizim senaryoya uyuyor. Çünkü bizde dert çoğu zaman “yeni kurulan ortama işi nasıl başlatacağız?” oluyor. Yeni mezun stajyer mi geldi, yeni geçen senior mı öldü, yoksa pazartesi günü gelen freelance dış kaynak mı? Bir komutla “ne eksik?” sorusuna cevap alabilmek fena değil; onboarding süresini günlerden saatlere çekebilir. Küçük ekipseniz buradan kazancınız bariz olur. Büyük kurumsal yapıdaysanız zaten muhtemelen kendi internal “dev environment bootstrap” script’leriniz vardır —. O script’lerin bakım maliyetini de düşünün, hani bazen asıl yük orada patlıyor; azd buna alternatif sunuyor.
Şahsen, Peki neden?
Neyse uzatmayalım: araçların kurulumu ve kontrolü tek yerden yapılınca iş biraz rahatlıyor. İlginç, değil mi? Bilhassa de aynı template’i defalarca ayağa kaldırıyorsanız, her seferinde aynı prerequisite kavgasını yapmak yerine otomasyonun omzunuza yük bindirmesini tercih edersiniz (bizzat test ettim)
azd exec: Script çalıştırırken Key Vault dramı sona eriyor
Bu özelliği ilk gördüğümde, açık konuşayım, “neden daha önce yoktu?” dedim. azd exec cross-platform bir komut. Script çalıştırıcısı; ama işin asıl numarası başka, çalıştırdığınız program azd’nın environment context’ını aynen devralıyor, yanı environment değişkenleri de geliyor, Key Vault’tan resolve edilen secret’lar da, hepsi otomatik şekilde önünüze düşüyor (en azından benim deneyimim böyle)
Peki bu pratikte ne demek? Şöyle düşünün. Bir post-deployment script’ınız var diyelim; mesela provisioning bittikten sonra bir SQL migration koşturacaksınız. Eski tarafta işler biraz uzuyordu, hatta bazen gereksiz yere uzuyordu.
- Önce
azd env get-valuesile değerleri çekiyordunuz - Sonra bunları bir
.envdosyasına yazıyordunuz - Key Vault secret’larını ayrıca
az keyvault secret showile alıyordunuz - En sonunda da script’i çalıştırıyordunuz, tabiî biraz dua ederek (bence en önemlisi)
Evet.
Garip gelecek ama, Yeni dünyada işe iş çok daha kısa bir yoldan gidiyor:
azd exec --./scripts/run-migration.shLafı gevelemeden söyleyeyim, hepsi bu kadar. Script artık azd’nın gözünden ortama bakıyor, Key Vault referansları kendi kendine çözülüyor, Windows’ta PowerShell kullanmışsınız ya da Linux/Mac tarafında bash’e geçmişsiniz fark etmiyor; geliştirici makinesi ile CI runner arasındaki davranış farkı da baya azalıyor.
Bu kısmı özellikle GitHub Actions ve Azure DevOps Pipelines tarafında işe yarar buluyorum. Azure DevOps Issuer Emekliye Ayrılıyor: WIF Geçişi Şart yazımda da değinmiştim, kimlik tarafı zaten başlı başına ayrı bir dert; azd exec en azından secret yönetimini toparlayıp insana biraz nefes veriyor.
Neyse, çok dağıtmadan şunu söyleyeyim: küçük gibi duran ama günlük akışta baya fark ettiren bir özellik bu. Peki, sız ne dersiniz?
Multi-layer Provisioning: dependsOn nihayet bizimle
Tuhaf ama, Provisioning katmanları arasındaki bağımlılık, hani kulağa biraz sıkıcı geliyor ya, işte tam o konu. Ama üretimde başına gelince insanın fikri değişiyor. Yeni azure.yaml içinde artık dependsOn alanı var,. A bitmeden B’nın başlamamasını açık açık söyleyebiliyorsunuz.
Eskiden azd tarafında iş biraz tahmin yürütmeye kalıyordu; çıktı ve girdi referanslarına bakıp implicit bir analiz yapıyordu, çoğu zaman da düzgün çalışıyordu. Çoğu zaman. Ama bir yerde koşullu kaynak yaratımı devreye girince tablo değişiyordu, sonra saatlerce “bu network niye önce kurulmadı?” diye debug modunda gezip duruyordunuz.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
services:
api:
project:./src/api
language: ts
host: containerapp
worker:
project:./src/worker
language: ts
host: containerapp
dependsOn:
— apiNet bir yapı olmuş, niyet de saklanmıyor. Yeni provisioning analyzer şimdi hem bu dependsOn — en azından ben öyle düşünüyorum — ilişkilerini hem de implicit bağımlılıkları birlikte tartıyor, üstüne cycle detection yapıyor; yanı yanlışlıkla iki katmanı birbirine doladıysanız, deploy daha başlamadan bunu yakalıyor. Güzel tarafı bu, ama dur bir saniye — asıl güzel tarafı hata patlamadan önce bunu görmeniz.
Evet.
Ctrl+C interactive prompt — küçük ama kıymetli
Bunu ayrıca söylemezsem içimde kalır. azd provision ya da azd up sırasında Ctrl+C’ye bastığınızda artık size soruyor: “Azure tarafındaki deployment’ı arkada devam ettireyim mi, yoksa iptal mi edeyim?” Kısa bir soru gibi dürüyor. Bazen bütün akışı kurtarıyor.
İlginç olan şu ki, Eskiden Ctrl+C biraz muğlaktı, yanı sız “tamam durdu” sanıyordunuz ama Azure tarafında resource’lar yarım yarım yaratılmaya devam edebiliyordu; sonra yeniden denediğinizde çakışma çıkıyor, sız de “ben bunu kapattım sanmıştım” diye kalıyordunuz. Açık konuşayım, bu prompt küçük bir detay gibi dursa da operasyon tarafında baya iş görüyor.
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
0 comments