Azure Developer CLI: Şubat 2026 Yenilikleri
Terminal Gücü: JMESPath ile JSON’u Parmaklarınızda Yoğurun
Şimdi şöyle… Bazen öyle JSON dump’larıyla uğraşıyorsun ki insanın sabrı sınıyor yahu! İşte orada azd’nın --query parametresi, yanında da JMESPath desteği (gerçekten telaffuz etmesi bile eğlenceli) devreye giriyor ve hayatı kolaylaştırıyor. Hani şu Python’la parseler yazmanın gereksiz olduğu yerler var ya — onlar için biçilmiş kaftan.
Ben bizzat yaşadım; koskoca bir Infrastructure as Code çıktısından sadece iki üç ID çekmem gerekiyordu, normalde script üstüne script yazardım. Şimdi terminalden hop diye alıyorum. Peki başka nasıl işe yarar sizce? Mesela veri denizinde “şu an elimde olması şart” dediğiniz alanlara mı ulaşmak istiyorsunuz? Hemen kısa bir numara göstereyim:
Şöyle söyleyeyim,
Bakın mesela:
azd env get-values --query "config.connectionString"
Elinizde ne varsa fazlasını direk çöpe atıyor gibi; tertemiz sadece ihtiyacınızı gösteriyor.
Ama şeyi söylemeden geçmeyeyim, “Ben zaten hepsini kullandığım komut satırıyla seçerim” diyenler olacaktır (saygı duydum). Yalnız bence bu tarz pratiklikler geleceğin otomasyonunun omurgasını oluşturacak – özellikle de CI/CD ile farklı servislere veri aktarılması gerekiyorsa elin eski shell hacklerine bulaşmasın derim.
— Bir tıkla iş bitiyor.
JMESPath’in bana göre en baba yanı? Script’te o kafayı yiyen regex kabusuna girmeden kurtuluyorsun dostum!
Bir düşünün bakayım hiç başınıza geldi mi?
Script’ınızın içine her seferinde başka bir değerin peşine düşüyorsunuz; kodu baka baka modifiye etmek yerine tek hamlede farklı alanları çekerek güncelleme stresinden paçayı kurtarıyorsunuz.
Nedir burada hissettiğiniz şey? Özgürlük! Evet evet… Tam olarak bu.
Dağıtımda Yeni Sayfa: App Service Slot Desteği ve Eksileri
Bir soru gelsin buradan — “Slot swap mı?” Hep karışıyor! Hayır hayır, kast edilen şey doğrudan istediğin deployment slot’a azd ile yayın yapmaktan ibaret.
Geçenlerde prod ortamında canary release’e kalkıştık (riskli iş ama lazım olunca kaçış yok), normalde upuzun scriptler yazılırdı — şimdi işe sadece ilgili parametreyle işi bitirdik.
Pratik kısmı acayip sadeleşti mesela:
- Karmaşık bash/fish script dizilerini unutuyorsun;
- Direkt atomik şekilde istediğin slota deploy;
- Sıfır hata toleransı mı dediler? Heh teorik olarak güzel ama tabiî ki pratikte biraz işler değişir — anlatacağım hani!
Ama şunu beyin kenarına not edin:
Her şey güllük gülistanlık değil – slot sayısı çoğaldıkça monitöring fazlasıyla karmaşıklaşıyor ve config farkları ya da trafik yönlendirme derken kafa yakabiliyor bazı durumlarda.
(Yanı sandığınız kadar bal kaymak olmayabilir)
Yeri gelmişken belirtmezsem olmaz – –subscription, –location, sağdan soldan istediğin ayarı flag olarak koyup anında çevreyi ya da deployment bölgesini bireysel belirleyebiliyorsun.
Mesela global ayarı değiştirmeye gerek yok; demo ortamını bir anda Almanya’da açıp test edebilirsin veya farklı substa hızlıca deploy… Hani eski.env kopyala-yapıştır yöntemi bana artık otomotiv sanayi gibi kalıyor.
Aman diyeyim yalnız – subscription değiştirdiğinde aynı resource group adlarını tekrar kullanırsan Allah korusun üstüne yazar gider bütün setup!
(evet, doğru duydunuz)
Azure Developer CLI’nın Şubat 2026 güncellemeleri; JSON sorgulama (JMESPath), App Service deployment slot yönetimi ve temel parametrelerle ortam seçimini daha hızlı hâle getiriyor.
| Özellik | Konu |
|---|---|
| JMESPath ile JSON sorgusu | --query ile sadece gereken alanları hızlı çekme |
| Deployment slot yönetimi | App Service slot’lara doğrudan azd ile yayın/deploy |
| Atomik parametre seçimi | --subscription, --location gibi flag’lerle hedefi net belirleme |
| Operasyonel etkiler | Slot sayısı arttıkça izleme ve konfig farkları karmaşıklaşabilir |
Not: JMESPath, regex/script karmaşasını azaltıp CI/CD otomasyonunu daha “tek hamlede” yönetmeye yardım eder.
Aklınızı Kaçıracaksınız! Flex Consumption Plan’da Uzaktan Build Dönemi Başladı!
Bazen insan kendi bilgisayarının RAM’iyle boğuşmaktan fenalık geçiriyor açıkçası! Lokal build’in eziyetine dayanamayanlardansanız buyurun size yeni özellik:remoteBuild. (en azından benim deneyimim böyle)
Denedim – bütün derleme yükünü Azure üstlenince makinem resmen nefes aldı yahu! Kendi CI/CD pipeline’larında ajanlara fiziksel yük binmediği için performans artışı inanılmaz bariz oluyor.
Küçük makineyle çalışan ekiplerin duaları kabul olmuş gibi.
- Düşük donanımlı makinelerde çalışırken net ilaç gibi geliyor.
- Ama bir dakika!: Remote build genelde ilk çalıştırmada beklediğinden uzun sürebilir – moral bozmayın hemen.
- Lokal ağ hızınız düşükse veya büyük dosya indirmeniz gerekiyorsa klasik lokal build hâlâ hız konusunda avantaj yaratabilir — tecrübeyle sabit…
Bence Microsoft’un attığı mantıklı adımlar bunlar fakat hâlâ test aşamalarında remote debug malum biraz sancılı gelişiyor.
Bilhassa production’da karşıma çıkan paket eksikleriyle haşır neşir oldum mesela.
Pürüzsüz değil evet. Lokal dertlerden uzaklaşmak isteyene merhem gibi çözüm denilebilir.
Eklentilerde Oyun Değişiyor mu? Versiyon Zorunluluğu & Dev Container Kolaylığı
Diyelim ki kendi extension’ın var veya dışardan eklentiyi takım projesine gömdün… Version drift korkulu rüyanız olmuştur illaki. Sonunda gem tutmuşlar:requiredAzdVersion (en azından benim deneyimim böyle). Artık hangi uzantının azd’nın hangi sürümüne ihtiyaç duyduğunu sıkıca sınırlandırabiliyorsun.
Büyük ekiplerin çilesi sona erdi desem abartmam!
Kendi gözlemimi ekleyeyim — dev container tarafındaki uzantı entegrasyonu çok hayat kurtardı açıkçası.
Geçen junior arkadaş docker-compose’da eksik eklenti yüzünden bütün gün boyunca DEBUG yaptı (sınır krizi geçirmek serbest). Şimdi devcontainer.json ile tüm bağımlılıkları tek seferde ekliyorsun – konteyner kalkınca her şey şıp diye hazır!
Buyurun buradan yakın…
Bunlar Yetmez Diyenlere Bonus Özellikler:
- AI coding agent auto-detection:
Artık azd komutu interaktif prompt’larla AI bot konuşmaları arasında farkı anlıyor ve saçma sapan manuel onay ekranlarından sizi hızlıca kurtarıyor.
Kendim hosted ajanlarda test ettim baya keyif aldım doğrusu.
Merak eden varsa detaya şuradan inebilir:
Azure Developer CLI ile Hosted AI Ajanlarını Terminalden Canlı Takip Etmek! - Klavye tuşu kaçamağı fix’i:
Bilen bilir Ghostty terminal kullanıcılarının başına bela olan yön tuşu saçmalığı sonunda tarihe karıştı!
Bazensade şeyler insana büyük konfor sunuyor:)
Kapanış & Eleştirel Bakış Açısı
Peki lafı çok dolandırmadan toparlayacak olsam ne söylerdim?
Azure Developer CLI’nın Şubat ’26 sürümü işleri sahiden kolaylaştırdı — tartışmasız gerçek bu fakat yeni özellik geldikçe sistemlerin karmaşıklığı ister istemez tavan yapıyor.[Eki bile kafam temiz anlatmak isterdi. Deneyimler böyle]
Bence, Peki hep ballandıra ballandıra iyi yanları anlattık da örtüsü altında sıkıntılar yok mu?
Tabiî ki var!
Slot yönetimi alışkanlıklarla pek bağdaşmıyor,QA ortamında iyice denemezsen bastığın komutta üretimde tatsız sürprizleri göze al kendin karar ver derim. Sorunsuz takılmanız için kontrollü olun yeter!
(Not düşüyorum!) Uçtan uca testlerde halen bazı noktalar atlanabiliyor… Aman dikkat 🙂
Unutmadan: Teknoloji hokus pokus değil ya – bugün çözmeye üşendiğiniz küçük sorun üç ay sonra size ‘vay anasını!’ dedirtebilir:)) İnce dokunuştan taviz vermeyin.
Daha fazla bilgi isteyenlere:
Vallahi, Kısacası: JMESPath’den remote build’e kadar Azd ciddi ciddi yeni ufuk açtı. Ama panik etmeye gerek yok;sadece önce ortamınızda deneyip öyle heyecanlanmakta fayda var demesi benden. Sız en çok hangi yeniliğe elinizi ovuşturuyordunuz?
Kaynak: Azure Developer CLI (azd) – February 2026: JMESPath Queries & Deployment Slots
Sıkça Sorulan Sorular
azd env get-values içinde JMESPath ile nasıl sadece belirli alanları çekebilirim?
azd env get-values komutuyla gelen JSON verisi içinde istediğin alanları JMESPath query’siyle filtreleyebilirsin. Örneğin config.connectionString gibi tek bir alanı hedefleyerek gereksiz çıktıyı eleyebilirsin. Ben altyapı çıktılarında sadece birkaç ID’ye ihtiyaç duyduğumda bu yöntemi çok sevdim; script üstüne script yazmaktan kurtarıyor.
–query parametresini kullanırken JMESPath’te hata alırsam ne yapmalıyım?
JMESPath query’sinde küçük bir yazım hatası bile sonucu boş döndürebilir ya da hata verebilir. Önce query’yi tek bir alan hedefleyecek şekilde sadeleştirip adım adım genişletmek en kolayı. Ayrıca komutun çıktısını kontrol edip JSON yapısının beklediğin gibi gelip gelmediğini görmek gerekiyor.
azd ile App Service deployment slot’a doğrudan nasıl yayın yapılıyor, slot swap mı yapıyor?
azd’nın slot yönetimi, klasik “slot swap” akışından ziyade doğrudan hedeflediğin deployment slot’a yayın yapmayı kastediyor. Yanı önce bir slot’a deploy edip sonra swap yapmak yerine, ilgili parametreyle istediğin slota çıkış alıyorsun. Bu yaklaşım canary release gibi senaryolarda işleri baya hızlandırıyor.
Deployment slot sayısı arttıkça hangi riskler veya zorluklar ortaya çıkabiliyor?
Slot sayısı çoğaldıkça monitöring, trafik yönlendirme ve ortam bazlı config farkları daha karmaşık hâle geliyor. Özellikle hangi slot’ta hangi ayarın yürürlükte olduğunu takip etmek zorlaşabiliyor. Benim deneyimimde en çok zaman alan kısım, “deploy tamam ama konfig doğru mu?” kontrolü oluyor.
azd komutlarında –subscription ve –location flag’lerini ne zaman kullanmalıyım?
Birden fazla Azure aboneliği veya bölgesiyle çalışıyorsan bu flag’ler hayat kurtarıyor. Komutu hangi subscription ve hangi location üzerinde çalıştıracağını netleştirerek yanlış ortama deploy riskini azaltıyorsun. CI/CD tarafında da bu şekilde parametreleri sabitlemek daha güvenli ilerlemeyi sağlıyor.
Kaynaklar ve İleri Okuma
Azure Developer CLI Resmî Dokümantasyonu
JMESPath Resmî Web Sitesi ve Dökümantasyonu
Azure App Service Deployment Slot’ları Hakkında Detaylar
Azure Blog: azd CLI App Service Slot Desteği
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.
