Mart 2026 güncellemelerine bakınca şunu düşündüm: azd artık sadece “uygulamayı buluta at” aracı olmaktan iyice çıkmış. Terminalin içine küçük bir operasyon merkezî koymuşlar gibi. Bir yanda AI agent’ları yerelde çalıştırma, izleme ve hata ayıklama; öte yanda GitHub Copilot ile proje kurulumunu hızlandırma; bir de Container App Jobs desteği… Kağıt üstünde iyi duruyor, pratikte de bayağı iş görüyor.
Açık konuşayım, ben bu tarz CLI güncellemelerinde genelde temkinliyim. Çünkü özellik listesi uzun olur, ama sahada ilk denemede yarısı tökezler. Yine de azd’nın bu türü fena değil. Bilhassa Azure danışmanlığı yaptığım projelerde, geliştirici ekiplerin “şu environment’ı kurana kadar gün bitti” dediği anları çok gördüm. İşte tam o noktada azd’nın yeni akışları ciddi fark yaratabiliyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Bir de şu var: bu sürümler sadece tek bir alana yüklenmiyor. Hem AI odaklı işler hem deployment tarafı hem de JavaScript/TypeScript projelerinde daha akıllı algılama var. Yani sadece yapay zekâ havası estirmiyor; günlük geliştirme acısını da azaltmaya çalışıyor. Bence önemli olan da bu zaten.
AI ajanlarını terminalden yönetmek neden önemli?
Benim en çok dikkatimi çeken parça, azure.ai.agents uzantısı oldu. Çünkü burada olay sadece “agent deploy et” değil; azd ai agent run, azd ai agent invoke, azd ai agent show, azd ai agent monitor gibi komutlarla uçtan uca bir döngü veriliyor. Yani geliştirici artık tarayıcı açıp sekme sekme gezmek yerine terminalde kalabiliyor. Kulağa küçük geliyor ama büyük ekiplerde zaman kazancı bayağı hissediliyor.
Geçen yıl Nisan 2025’te bir finans müşterisinde benzer bir sıkıntı yaşamıştık. Geliştiriciler agent davranışını test etmek için sürekli portal ile local ortam arasında gidip geliyordu. Logosoft tarafında yaptığımız tasarım oturumunda şunu net görmüştük: bağlam ne kadar dağılıyorsa hata ayıklama süresi de o kadar uzuyor. Buradaki yeni yaklaşım tam tersini hedefliyor; işi tek pencereye topluyor.
azd ai agent monitor gibi komutların kıymeti özellikle üretimde ortaya çıkıyor. Mesela ajan container’ı ayağa kalktı mı, health check geçti mi, loglarda hangi satırda patladı… Bunları canlı görmek güzel şey. Ama her şey güllük gülistanlık değil: yerel çalıştırma deneyimi bazı senaryolarda production’a göre farklı davranabilir, özellikle ağ erişimi ve kimlik doğrulama tarafında.
Terminalden ajanın ne yaptığını görmek, sorun çıktığında “acaba nerede koptu?” sorusunu yarıya indiriyor. Ekip kalabalıksa bu bayağı rahatlatıyor.
Yerel test mi, Foundry’ye deploy mu?
Bence asıl güzel taraf burada başlıyor. Yerelde koşup sonra Microsoft Foundry’ye gönderebilmek, aynı mantığı iki dünyada da kullanabilmek ekipler için temiz bir akış veriyor. Küçük startup’ta bunu hızlı prototipleme için kullanırsın; enterprise tarafta işe güvenlik ve gözlemlenebilirlik katmanlarını ekleyip kontrollü ilerlersin.
2019’da kendi lab ortamımda buna benzeyen bir düzen kurmaya çalışmıştım ama araçlar bugünkü kadar pürüzsüz değildi. O dönem her şey biraz el yordamıyla yürüyordu; config dosyası ayrı dertti, log takibi ayrı dertti… Şimdi azd bunu daha derli toplu yapmaya çalışıyor. Daha fazla bilgi için Kubernetes’te AI Dönemi: Microsoft’un KubeCon 2026 Hamlesi yazımıza bakabilirsiniz.
GitHub Copilot ile azd init akışı nasıl değişiyor?
azd init içine GitHub Copilot entegrasyonu eklenmesi bence en kullanıcı dostu hamlelerden biri olmuş. Yeni başlayan biri için proje iskeleti kurmak çoğu zaman “hangi klasöre ne koyacağım” karmaşasına dönüşüyor. Copilot destekli başlangıç seçeneği bu karmaşayı biraz yumuşatıyor.
Neyse, burada kritik detay şu: araç önce working directory’nın temiz olup olmadığını kontrol ediyor ve ardından MCP server tool consent istiyor. Bu kötü mü? Hayır, tam tersi güven açısından iyi düşünülmüş. Ben güvenlik tarafında çalışan biri olarak böyle upfront onay mekanizmalarını seviyorum; çünkü sonradan gelen sürprizler genelde tatsız oluyor.
Ama ufak bir hayal kırıklığı notu da düşeyim: AI destekli scaffolding bazen hızlıdır ama her zaman doğru mimariyi seçmez. Hani ilk taslağı verir, sonrası yine sizin omzunuzda kalır ya… işte burada da durum biraz öyle olabilir. AZ-305 hazırlığında öğrendiğimiz klasik ders değişmiyor: araç fikir verir, mimarı kararı siz verirsiniz. Daha fazla bilgi için Visual Studio Aboneliğinde Gizli Güç: Syncfusion’ı Kaçırmayın yazımıza bakabilirsiniz.
Deployment tarafında neler daha rahat?
Container App Jobs desteği, mart güncellemelerinin sessiz ama etkili parçalarından biri bence. Daha önce belirli iş yüklerini schedule/worker mantığında yönetirken ekstra uğraş çıkabiliyordu. Şimdi host: containerapp yapılandırması üzerinden job türünü template belirliyor ve ekstra konfigürasyon istemiyor gibi anlatılmış.
Buna benzer bir ihtiyacı geçen sene Ekim 2025’te telekom sektöründe çalışan bir müşterimizde yaşamıştık. Kısa süreli batch işleri için klasik web app modeli fazla ağır kalıyordu; Container Apps fikri uygun görünüyordu ama job senaryosu netleşmeyince yapı biraz yamuk durdu. Böyle anlarda doğru hosting modelini seçmek gerçekten oyunun yarısı. Daha fazla bilgi için GitHub Copilot for Jira: Preview’de Neler Sıkılaştı? yazımıza bakabilirsiniz.
| Konu | Klasik yaklaşım | Yeni azd yaklaşımı |
|---|---|---|
| Ajan testi | Ayrı araçlar + portal geçişi | Terminal içinde run/invoke/monitor |
| Paket algılama | Sıklıkla manuel kontrol gerekir | Pnpm / yarn otomatik algılama |
| Zaman aşımı yönetimi | Tek tip timeout çoğu zaman yetmez | -timeout, servis bazlı kontrol sağlar |
| Copilot ile kurulum | Daha çok elle scaffolding | azd init içinde AI destekli başlangıç |
Ne yalan söyleyeyim, burada herkesin mutlu olacağı nokta yok; jobs tarafında template’in doğru yazılması hâlâ önemli. Araç kolaylaştırıyor ama yanlış Bicep veya yanlış uygulama modeli seçerseniz sihir bozulur. Bulut dünyasında sihir zaten pek uzun sürmez. GitHub Güvenliği: Küçük Repoda Büyük Açıkları Kapatmak yazımızda bu konuya da değinmiştik.
Zaman aşımı ayarı neden değerli?
--timeout bayrağı ve deployTimeout alanı bana oldukça mantıklı geldi. Çünkü bazı servisler vardır, bekletir de bekletir! Mesela veri migration yapan ya da ağır container build geçen projelerde sabit timeout yüzünden gereksiz fail görmek can sıkar. GitHub’ın EU Veri Yerleşimi Neden Bir Anda Büyüdü? yazımızda da bu konuya değinmiştik.
# Örnek kullanım
azd deploy --service api --timeout 1800
# azure.yaml örneği
services:
api:
project: ./src/api
host: containerapp
deployTimeout: 1800Küçük startup ile enterprise arasında fark ne?
Küçük bir detay: Küçük startup için bu yeniliklerin ana faydası hızdır. Tek kişi hem kod yazıp hem deployment yapıyorsa azd’nın otomasyonları nefes aldırır. Bilhassa pnpm/yarn algılama ve Copilot destekli setup kısmı “ilk çalışan demo”ya giden yolu kısaltır.
Büyük kurumlarda işe tablo biraz farklıdır; orada hız kadar standartlaşma da önemlidir! Az önce startupta “hız kazanırsın” dedim ama enterprise’da asıl soru şudur: Bu hız governance’i delmeden geliyor mu? AZ-500 ve AZ-104 tecrübemde gördüğüm şey şu ki güvenlik kapıları kapalıysa hiçbir kolaylık uzun ömürlü olmaz.
Lafı gevelemeden söyleyeyim: küçük ekiplerde azd daha pratik hissettirir, büyük yapılarda işe platform engineering disipliniyle birlikte anlam kazanır. Yoksa herkes kendi workflow’unu üretirse ortalık biraz karışır… hani klasik kablo yumağı gibi.
- Ajan odaklı projelerde terminal içi debug döngüsü ciddi zaman kazandırır.
- Copilot destekli başlangıç yeni ekip üyelerini hızla oyuna sokar.
- Cihaz değil süreç önemliyse timeout ayarı gerçek kurtarıcı olur.
- Buna karşılık yanlış standartlar varsa otomasyon sadece hatayı hızlı yayar.
- Bence en iyi sonuç, azd + IaC + policy üçlüsüyle geliyor.
Sahada dikkat ettiğim pratik noktalar
Mart release notlarına bakarken en çok düşündüğüm şey şu oldu: “Bu özellikler demo’da mı iyi duruyor, yoksa gerçek iş yükünde mi?” Çünkü ikisi aynı şey değil! Mesela local preflight validation kulağa basit geliyor ama infrastructure hatasını deploy’dan önce yakalayabildiğinde gecenin köründe alarm yemekten kurtuluyorsun.
Ankara’da Kasım 2025’te görüştüğüm bir e-ticaret ekibi vardı; onların ana derdi yanlış parametreyle çıkan deployment fail’leriydi. Preflight validation olsaydı birkaç saatleri geri gelirdi diye pek çoğu düşünmüştü o gün. Bir de pnpm/yarn auto-detection detayı var — küçük gibi görünür. Monorepo yaşayanlar bilir, paket yöneticisini yanlış okumak insanın moralini düşürür.
Neyse uzatmayayım, benim önerim şu olur:
- Kritik servislerde timeout’u servis bazında ayarla.
- Copilot ile scaffold edilen dosyaları mutlaka code review’dan geçir.
- Ajan loglarını yerelde tutup prod davranışıyla karşılaştır.
- Bicep template’in job/app ayrımını net test et.
- Ekip standardını baştan yaz ki herkes kendi kafasına göre ilerlemesin.
Sıkça Sorulan Sorular
azd nedir?
Azure Developer CLI (azd), Azure uygulamalarını daha hızlı oluşturup dağıtmak için kullanılan komut satırı aracıdır. Mart 2026 güncellemesiyle AI ajanları ve GitHub Copilot entegrasyonu gibi özelliklerle daha güçlü hâle geldi.
azd ile AI ajanlarını yerelde çalıştırabilir mıyım?
Evet. azd ai agent run ile ajanı yerelde başlatıp azd ai agent invoke ile test edebilir, azd ai agent monitor ile de loglarını canlı takip edebilirsiniz. Hazır olduğunda aynı akışla Microsoft Foundry’ye deploy etmek de mümkün.
İçeriği paylaş:
İlgili Yazılar
📬 Bu yazıyı faydalı buldunuz mu?
Azure, DevOps ve bulut teknolojileri hakkında güncel içerikler için beni takip edin!
Yorum gönder