azd update Komutu: Paket Yöneticisi Derdine Son

Bir şey anlatayım. Geçen ay bir müşterimde Azure Developer CLI ile proje deploy ediyorduk, tam her şey rayına oturmuşken azd bir anda “yeni versiyon var” diye dürttü. Tamam dedim, güncelleyelim. Sonra durup düşündüm — bu makineye azd’yi ilk başta nasıl kurmuştuk? winget mi, curl script’i mi, yoksa Chocolatey mi? Hatırlamıyorum. Cidden hatırlamıyorum.

Yanı, İşte burada Microsoft’un sessiz sedasız getirdiği azd update komutu devreye giriyor. Basit görünüyor, değil mi? Tek komutla güncelleme yapıyorsunuz; ama işin aslı, bunun arkasında geliştirici deneyimini baya toparlayan bir detay var (özellikle ortamı kim kurduysa ortada kayboluyorsa). Peki neden bu kadar iş görüyor? Çünkü kurulum yöntemini tek tek hatırlama derdini ortadan kaldırıyor.

Sorun Ne, Neden Bu Kadar Büyütüyoruz?

Bakın şimdi, Azure Developer CLI’ı farklı şekillerde kurabiliyorsunuz. Windows’ta winget ya da Chocolatey ile, macOS’ta Homebrew ile, Linux’ta işe çoğu zaman curl script’i veya apt ile gidiliyor. Her platformun güncelleme komutu da ayrı; winget upgrade, brew upgrade, choco upgrade… Hangisi hangisiydi, insan bir an durup bakıyor.

Bunu tek kişi için düşününce idare eder. Ama 15 kişilik bir DevOps ekibinde işler karışıyor; herkesin makinesi başka türlü kurulmuş oluyor, biri WSL kullanıyor, biri direkt PowerShell’den kurmuş, biri de “ben hatırlamıyorum, sanırım script’le yaptım” diyor. Güncelleme yapmak bile küçük bir toplantıya dönüyor, hani bazen asıl işten çok bunu konuşuyorsunuz ya, işte o nokta biraz can sıkıyor.

Logosoft’ta bir e-ticaret müşterimizde tam olarak bunu yaşadık — 2024 sonlarında. Ekipte 8 geliştirici vardı, hepsi azd kullanıyordu ama kurulum yöntemleri birbirinden farklıydı. Birinde azd 1.19 vardı, diğerinde 1.21; versiyon farkı yüzünden template davranışları bile değişiyordu (ufak gibi duran şeyler bazen en çok oradan vuruyor), bir bug fix’i almak için herkesin güncellemesi gerekti. “nasıl güncelleme yapacağım” sorusu ciddi zaman yedi.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Erteleme refleksi — hepimiz biliyoruz

“Yeni versiyon var” uyarısını görünce ne yapıyoruz? “Sonra yaparım.” Sonra unutuyoruz. Sonra bir bug’a çarpıyoruz; saatler gidiyor, sınır bozuluyor ve en sonunda öğreniyoruz ki o bug iki versiyon önce düzeltilmiş. Klasik mi klasik. Bende de öldü, sizde de olmuştur.

azd update Tam Olarak Ne Yapıyor?

Hani, Komut aslında baya sade. Terminali açıyorsun, sonra tek satır yazıyorsun:

azd update

Hepsi bu.

Bak şimdi, işin güzel tarafı burada: azd hangi yöntemle kurulduysa önü kendi buluyor. Güncellemeyi de aynı yoldan yapıyor, yanı winget ile geldiyse winget’e dönüyor, Homebrew ile geldiyse brew tarafına gidiyor, script ile kurulmuşsa o akışı kullanıyor; sen de ortada “şimdi ben ne yapacaktım” diye düşünmüyorsun.

Peki günlük build’ler lazım olursa? O zaman --channel flag’i devreye giriyor:

azd update --channel daily

Şunu söyleyeyim, Stabil kanala dönmek de ayrı bir komutla oluyor:

azd update --channel stable

Bu özellik azd 1.23.x ile gelmişti. Daha eski bir sürüm kullanıyorsan, evet, maalesef bir kez daha eski usül güncelleme yapman gerekiyor; sonra iş rahatlıyor ve bundan sonrası için sadece azd update demen yetiyor.

Platform Bazlı Karşılaştırma: Eski Dünya vs. Yeni Dünya

Şimdi tabloyu ortaya koyunca iş biraz netleşiyor. Bakın, eski yöntemle yeniyi yan yana koyduğunuzda fark hemen göze çarpıyor, hem de öyle küçük bir fark değil; Windows’ta winget, Chocolatey, macOS’ta Homebrew, Linux’ta script derken insan bir noktada “ben bunu hangi yolla kurmuştum?” diye kalıyordu.

Kısacası tek komuta dönmüş. İşte, evet, bu kadar basit. Beş ayrı senaryo için beş ayrı yolu ezberlemek yerine artık aynı komutla ilerliyorsunuz; açık konuşayım, bu da günlük işte baya rahatlatıyor çünkü hangi kurulum kanalını kullandığınızla uğraşmıyorsunuz, sadece güncelle deyip geçiyorsunuz.

Türkiye’deki Ekipler İçin Neden Mesela Önemli?

Şimdi biraz yerel bağlam katayım, çünkü bu konuyu Türkiye’deki şirketler açısından düşününce iş değişiyor. Kağıt üstünde basit duran şey, sahada bazen ufak bir maceraya dönüşüyor.

Türkiye’deki yazılım ekiplerinin çoğunda — özellikle orta ölçekli şirketlerde — standart bir geliştirici ortamı (developer environment) tanımı yok. Herkes kendi makinesini kendi kuruyor; biri Windows 11 Pro kullanıyor, diğeri Windows 10, öbürü macOS, bir başkası Ubuntu. Araçları kimin nasıl kurduğu bayağı kişiye bağlı kalınca, azd gibi bir CLI aracının güncellemesini yönetmek bile ayrı dert oluyor.

Geçen sene bir finans kuruluşunda danışmanlık yaparken — tam olarak İstanbul’da, büyük bir sigorta şirketiydi — DevOps ekibinin 6 kişiden oluştuğunu gördüm. Hepsi azd kullanıyordu ama versiyonlar birbirini tutmuyordu. Bir tanesi “ben Chocolatey bilmem, curl script çalıştırmıştım” dedi. Diğeri “benim makinede winget yok ki” dedi. Böyle durumlarda azd update sadece teknik bir kolaylık olmuyor; açık konuşayım, operasyon tarafında baya iş görüyor.

Bir CLI aracını güncellemek kolay olmalı. Eğer güncelleme süreci aracın kendisini kullanmaktan daha karmaşıksa, bir yerde bir şeyler yanlış gidiyordur.

Enterprise vs. Startup: Farklı Senaryolar

Küçük bir ekipseniz — hani 3-5 kişilik startup — bu mesele bazen çok da büyümüyor. Herkes birbirinin makinesini biliyor, Slack’ten “hepiniz winget upgrade yapın” deyince konu kapanıyor gibi oluyor. Ama 50+ kişilik kurumsal yapıda? Orada Intune ya da SCCM üzerinden paket dağıtımı dönüyor, CI/CD agent’larında azd versiyonu pipeline tanımında sabitlenmiş oluyor (evet, doğru duydunuz). İşte o noktada tek komutla güncelleme yapmak ciddi fark yaratıyor. Bu konuyla ilgili Ingress2Gateway 1.0: Ingress’ten Gateway API’ye… yazımıza da göz atmanızı tavsiye ederim.

Aslında, Ha, bir de şu var: CI/CD pipeline’larında azd kullanıyorsanız, agent imajlarını güncellerken de bu komut işinize yarıyor. Pipeline YAML dosyasına bir azd update step’i koyuyorsunuz, her çalışmada güncel versiyonu alıyor. Tabi daily channel’a bağlamayın bunu — stabil kalın; yoksa bir sabah uyanırsınız ve pipeline kırılmış olur (inanın bana) Daha fazla bilgi için GitHub’da Deployment Context: Repo ve Alert Yön… yazımıza bakabilirsiniz.

İlk Kurulum Sonrası Yapılacaklar

İtiraf edeyim, Eğer azd’yi daha önce hiç kurmadıysanız, ya da elinizde baya eski bir sürüm varsa, işe böyle girin. Kısa yol yok. Önce neyin nerede olduğunu görün, sonra güncellemeye geçin; çünkü bazen insan “bir komut çalıştırayım bitsin” diyor. Iş öyle yürümüyor. .NET ve .NET Framework Nisan 2026 Güvenlik Yama… yazımızda bu konuya da değinmiştik.

1. Önce mevcut versiyonunuzu kontrol edin: azd version
2. 1.23.x altındaysanız, son bir kez eski yöntemle güncelleyin (winget, brew, choco — hangisini kullandıysanız) — bunu es geçmeyin
3. 1.23.x veya üzerindeyseniz, artık azd update yeterli
4. İlk defa kuruyorsanız: Azure Developer CLI kurulum sayfasından başlayın

Şöyle söyleyeyim, Peki neden böyle? Çünkü 1.23.x sınırı burada kritik rol oynuyor, yanı eski sürümlerde klasik paket yöneticisiyle bir tür daha atmak gerekiyor, ama yeni sürümde iş basitleşiyor (ve açıkçası bu tarafı fena değil), sonra da azd update ile devam ediyorsunuz.

Bir dakika. Kurulumdan sonra azd auth login yapmayı atlamayın. Güncelleme çoğu zaman auth token’ı yerinde bırakıyor,. Bazen — özellikle majör sürüm atladıysanız — yeniden giriş istiyor. Ben bunu ilk kez yaşadığımda 15 dakika boyunca “niye çalışmıyor bu” diye ekranı seyrettim; meğer token expire olmuş ve update sırasında temizlenmiş.

Tam da öyle.

Eksik Kalan Şeyler ve Eleştirilerim

Her şey fena değil ama, açık konuşayım, birkaç yerde yüzüm biraz düştü.

Birincisi, azd update otomatik güncelleme yapmıyor. Yanı komutu sız çalıştırıyorsunuz, o kadar. “Kendi kendine arka planda güncellensin” gibi bir seçenek yok, en azından bugün için (ilk duyduğumda inanamadım). VS Code eklentileri bile bazen sessiz sedasız yenilenirken, bir CLI aracının hâlâ manuel müdahale istemesi biraz eski moda hissettiriyor; tabi otomatik güncelleme üretimde risk de çıkarabilir, o ayrı konu, ama yine de azd config set auto-update true gibi opsiyonel bir ayar görsem hiç fena olmazdı.

İkincisi — burası biraz can sıkıcı — daily channel’dan stable’a dönerken bazen garip şeyler oluyor. Bir kere daily build’i kurcaladım, sonra “tamam, stable’a dönelim” dedim ve azd update --channel stable çalıştırdım; ama versiyon numarası hâlâ daily tarafını andırıyordu. Tekrar denedim, düzeldi. Küçük bir detay gibi dürüyor ama insanın aklının köşesine takılıyor, hani “acaba başka yerde de aynı sürpriz var mı?” diye düşündürtüyor.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Üçüncüsü: proxy arkasındaki kurumsal ağlarda iş bazen yavaşlıyor (en azından benim deneyimim böyle). Türkiye’deki büyük kurumların çoğu — bankalar, — ki bu tartışılır — telekom şirketleri, kamu tarafı — proxy kullanıyor, bunu zaten biliyoruz. Peki azd update bu senaryoda ne kadar rahat çalışıyor? Resmî dokümanda net bir cümle yakalayamadım. Bunu ayrıca test etmek gerekecek. HTTP_PROXY ve HTTPS_PROXY environment variable’ları çoğu zaman işi görüyor, evet, ama her ortamda taşlar yerine oturur mu, ona şu an %100 güvenemem.

Evet. Bu konuyla ilgili MSVC 14.51 ile C++23 Desteği: Sahadan Notlar yazımıza da göz atmanızı tavsiye ederim.

Bazen mesele özellik değil.

Neyse uzatmayayım; araç iyi gidiyor ama bu üç nokta benim aklımda kaldı (ciddiyim) Kubernetes 1.36 Ön İzleme: Neler Geliyor, Neler… yazımızda bu konuya da değinmiştik.

Pratik İpucu: Pipeline’da Versiyon Sabitleme

CI/CD pipeline’ınızda azd kullanıyorsanız, küçük gibi görünen ama işi baya etkileyen bir noktaya takılın derim. Her çalıştırmada azd update koşturmak yerine, belli bir versiyonu sabitleyip sadece planlı aralıklarla güncellemek daha sakın ilerliyor. Peki neden? Çünkü bir sabah pipeline kalkıyor, azd 1.24’e geçiyor ve yeni sürümdeki minicik bir breaking change yüzünden deployment duvara tosluyor. Bunu yaşadım, yanı öyle teorik konuşmuyorum. Cuma akşamı her şey yolunda gidiyor, Pazartesi sabahı “azd provision” hata veriyor; sonra bakıyorsunuz, arada yeni versiyon gelmiş ve template parametresi ufak ama can sıkıcı biçimde değişmiş.

# Örnek GitHub Actions step'i
- name: Update azd (kontrollü)
run: |
azd version
azd update --channel stable
azd version

Bu yaklaşımın güzel tarafı şu: loglara bakınca hangi sürümden hangisine geçtiğinizi net görüyorsunuz. Evet, bu kadar basit. Ama dur bir saniye — daha da temizi ne olabilir derseniz, azd’yi Docker imajının içinde sabit bir versiyonla kullanmak da fena değil; hatta bazı ekiplerde açıkçası daha rahat ediyorlar. Yine de her senaryoya tek reçete yazmak zor, ortamınıza göre karar vermek lazım.

Kısa bir not düşeyim buraya.

CLI araçlarının paketlenme ve dağıtılma şekli epey değişiyor, işin aslı biraz da buradan çıkıyor zaten. Nitekim PowerShell tarafında da benzer bir dönüşüm gördük — PowerShell’de MSI Dönemi Bitiyor: MSIX’e Geçiş Rehberi yazımda bu konuya değinmiştim. Şey gibi düşünün; bugün normal gelen yöntem yarın biraz eski kalabiliyor. Neyse uzatmayalım, pipeline’da sürümü kontrolsüz bırakmamak çoğu zaman baş ağrısını ciddi şekilde azaltıyor.

Peki GitHub Copilot CLI ile Farkı Ne?

Hmm, bir düşüneyim… Aslında bunu bire bir kıyaslamak pek doğru değil, çünkü ikisi aynı işi yapmıyor. Yine de kurulum ve güncelleme tarafında benzer pürüzler var; GitHub Copilot CLI da bazen insanı uğraştırıyor, özellikle ilk kurulumda ve yapılandırma kısmında (hani “iki komutla biter” deniyor ya, bazen hiç öyle olmuyor). Eğer o tarafa da bakıyorsanız, GitHub Copilot CLI Nedir. Nasıl Kurulur: İlk Adımlar yazıma göz atın.

Bir dakika — bununla bitmedi.

Vallahi, Gel gelelim asıl meseleye. Microsoft’un CLI araçlarında böyle bir “self-update” alışkanlığı oluşuyor gibi dürüyor; az önce az upgrade vardı, şimdi azd tarafına da geldi, yanı iş biraz rayına oturuyor gibi ama tam oturdu da diyemem. Umarım ileride neredeyse tüm Microsoft CLI araçları aynı dili konuşur (çünkü kullanıcı tarafında tutarlılık iyi şey), hatta belki bir gün az tool update --all gibi tek komutla hepsini topluca güncelleriz… Evet, kulağa biraz hayal gibi geliyor ama fena fikir değil.

Sıkça Sorulan Sorular

azd update komutu hangi versiyondan itibaren çalışıyor?

Aslında bu özellik azd 1.23.x ve üzeri versiyonlarda geliyor. Sız ne dersiniz? Daha açık söyleyeyim, daha eski bir versiyondaysanız, önce eski kurulum yönteminizle (winget, brew, choco veya script) bir kerelik manuel güncelleme yapmanız gerekiyor.

Ve işler burada ilginçleşiyor.

azd update çalıştırınca mevcut projelerim etkilenir mi?

Hayır, hiçbir şey değişmiyor — güncelleme sadece azd CLI binary’sını değiştiriyor. Projeleriniz, template’leriniz ve konfigürasyonlarınız yerli yerinde kalıyor. Ama majör versiyon atlıyorsanız, auth token’ınızı yeniden almanız gerekebilir. E peki, sonuç ne öldü? Açıkçası bunu atlayan çok insan var, azd auth login ile bir kontrol edin derim.

Daily channel nedir, üretim ortamında kullanmalı mıyım?

Daily channel, yanı henüz stabil sürüme girmemiş yeni özellikleri erken test etmenizi sağlayan kanal (kendi tecrübem). Üretimde? Vallahi hayır. Geliştirme ve test için ideal ama bence pipeline’larınızda stabil kanalda kalın, gereksiz risk almayın.

Proxy arkasında azd update çalışıyor mu?

Resmî dokümantasyonda net bir açıklama yok açıkçası. Ama HTTP_PROXY ve HTTPS_PROXY environment variable’larını ayarlayarak çoğu kurumsal ağda çalıştırabilirsiniz. Sorun yaşarsanız GitHub Issues üzerinden bildirim yapmanızı öneririm — tecrübeme göre bu tür geri bildirimler oldukça hızlı ele alınıyor.

azd update ile az upgrade aynı şey mi?

Hayır, bunlar tamamen farklı araçlar. az upgrade Azure CLI’ı (az) güncellerken, azd update Azure Developer CLI’ı (azd) güncelliyor. Yanı, az hani daha genel amaçlı bir Azure yönetim aracıyken, azd uygulama geliştirme ve deployment odaklı çalışıyor. İkisini karıştırmak çok kolay, dikkat edin (yanlış duymadınız)

Kaynaklar ve İleri Okuma

Azure Developer CLI Kurulum ve Güncelleme Dokümantasyonu

Bi saniye — Azure SDK Blog: Stop juggling package managers—just run azd update

Kendi deneyimimden konuşuyorum, GitHub PR #6942 — azd update özelliğinin kaynak kodu

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Azure CLI ile Hosted AI Ajanlarını Canlı Takip14 Mar 2026

VS Debugger Agent: Bug Avı Artık Ajan İşi16 Nis 2026

Azure MCP Server 1.0 Yayında: Bulut Otomasyonunda Yepyeni Bir Perde Açıldı18 Mar 2026

.NET MAUI 11 Harita Pin Kümeleme: Sahadan Rehber16 Nis 2026