Şöyle başlayayım: Geçen hafta bir müşteride, çok sevdiğim bir geliştirici arkadaşımız azd‘yi güncellemeye çalışıyordu. Yarım saat geçti. Hâlâ ugrasıyor. Sordum: “Ne öldü?” Cevap biraz can yakıcıydı (belki yanılıyorum ama) — “Bu makineye azd’yi nasıl kurmuştum hatırlamıyorum. Winget mi, Chocolatey mi, yoksa script mi?” Tanıdık geldi mi?
Azure Developer CLI yanı azd, son iki yılda işimizi baya rahatlattı. Template’lerle proje başlatmak, infra ile app’i birlikte deploy etmek, CI/CD’yi bağlamak — hepsi tek bir tool’un altında toplanıyor. Ama bir tarafı hep biraz yamuktu: güncelleme. Her platformda başka komut, başka yol; açık konuşayım, insanın canını sıkıyordu. Şimdi Microsoft bu mevzuyu toparlıyor: azd update komutu geldi. Dürüst olayım, “bunu neden daha önce koymadınız?” dedirtiyor.
Hikâye nereden başlıyor?
Doğrusu, Bakın şimdi, azd‘nın kurulum tarafı biraz dağınık. Windows’ta winget ya da Chocolatey, macOS’ta Homebrew, Linux’ta işe genelde curl ile çekilen bir install script… Hepsinin güncelleme komutu ayrı, isimler benzer. Davranışları farklı, bir de üstüne ezberlemesi gerekiyor; açık konuşayım, insanın kafası çabuk karışıyor.
Araya gireyim: Sonuç mu? Herkes “yeni sürüm var” uyarısını görüyor, sonra “ya sonra bakarım” deyip kapatıyor. E sonra? İki hafta önce fix edilmiş bir bug’a denk gelince saatler gidiyor. Klasik. Ben bunu kendi laptopumda da yaşadım; Logosoft’ta bir bankacılık projesinin demo gününde azd up patladı, üç saat boyunca template versiyonunu suçladım (insan önce oraya gidiyor zaten), meğer benim azd 1.11’miş ve template 1.19+ istiyormuş. O sabah içtiğim kahvenin tadı hâlâ aklımda.
Tam da öyle.
azd update tam olarak ne yapıyor?
Tek cümleyle söyleyeyim: hangı paket yöneticisiyle kurduysanız kursun, doğru güncelleme yolunu kendi buluyor ve uyguluyor. Yanı “ben bunu winget ile mi kurmuştum, brew müydü, choco müydü?” diye kafa yormanıza gerek kalmıyor. Komut da zaten baya sade:
azd updateBu kadar. Stable kanaldan en güncel sürüme geçiyor. Peki neden güzel? Çünkü bir yerde işi elle yaparken başka yerde aynı komutla akışı bozmuyorsunuz; ama dür bir saniye — yeni özellikleri erkenden kurcalamak isteyenler için de kapı açık, ben mesela geliştirme makinemde çoğu zaman oraya bakıyorum.
# Daily insiders build'e geç
azd update --channel daily
# Stable'a geri dön
azd update --channel stableBu --channel bayrağı bence iş görüyor. Production makinelerinde stable bırakıp, deneme ortamında daily kullanabiliyorsunuz; yanı ayrım net, kafa karıştırmıyor. Visual Studio’daki Preview/Release mantığına benziyor biraz, hatta tam üstüne oturuyor gıbı,. Yine de birebir aynı demem.
Evet, doğru duydunuz.
Hangı sürümden itibaren?
Komut azd 1.23.x ile gelmiş. Bunu kontrol etmek için tek yapmanız gereken şu komutu çalıştırmak:
azd versionEğer daha eski bir sürüm kullanıyorsanız, son bir kez eski usul güncelleme yapmanız gerekecek; yanı winget, brew ya da choco hangisini kullandıysanız onunla. Ondan sonra azd update devreye giriyor ve işi sizden alıyor. Açık konuşayım, bu biraz son manuel yağ değişimi gıbı; sonrası otomatik servis, rahatlık orada başlıyor.
Evet.
Platform bazlı durum: tablo hâlinde
İşin teknik tarafına biraz daha bakalım. Aşağıdaki tablo, neyin değiştiğini tek bakışta gösteriyor:
| Platform | Önceki güncelleme komutu | Şimdi |
|---|---|---|
| Windows (winget) | winget upgrade Microsoft.Azd |
azd update |
| Windows (Chocolatey) | choco upgrade azd |
azd update |
| macOS (Homebrew) | brew upgrade azd |
azd update |
| Linux (script) | curl ile script’i tekrar çekme | azd update |
Tabloya bakınca olay baya sade görünüyor. Ama işin aslı o kadar düz değil; bu “sadelik”, yıllar süren bir geri bildirim döngüsünün sonunda geldi. GitHub’daki issue #6673‘e göz atarsanız, kullanıcıların bunu ne kadar uzun zamandır istediğini hemen fark ediyorsunuz. Yanı Microsoft bu kez gerçekten dinlemiş, açık konuşayım, bu da fena değil.
Evet.
“Geliştirici araçlarının en sevdiğim tarafı, hayatımızda çok yer kaplamamalarıdır.
azd updatede tam burada duruyor — görünmez gıbı, ama lazım olduğunda orada olduğunu hissettiriyor.”
Peki neden bu kadar hoşuma gitti? Çünkü eskiden platforma göre başka komut ezberliyorduk, şimdi işe tek bir alışkanlık yetiyor; hani küçük gıbı duran ama günlük kullanımda baya iş gören değişiklikler vardır ya, işte tam öyle bir şey. Az önce basit dedim ama aslında kullanıcı deneyimi tarafında epey temiz bir dokunuş bu.
İlginç olan şu ki, Tam da öyle.
Türkiye’deki ekipler için ne anlama geliyor?
Kurumsal müşterilerde gördüğüm tablo şu: Türkiye’de azd hâlâ çok yaygın değil. Hani şaşırtıcı da değil aslında. Ekiplerin bir kısmı Bicep ile GitHub Actions’ı kendi eliyle kurcalamayı seviyor, bir kısmı template işine biraz mesafeli duruyor, bir kısmı da dokümantasyon İngilizce olunca frene basıyor; üstüne bir de güvenlik ekipleri “internetten otomatik bir şey çekiyor” cümlesini duyunca kaşını kaldırıyor. Copilot Usage Metrics API: Artık Kohortlu AI Adopsiyon Devri yazımızda bu konuya da değinmiştik.
İşte tam burada azd update devreye giriyor. Çünkü merkezî yönetim tarafında iş baya toparlıyor. Bir bankada ya da telekomda, “developer’lar şu an hangı sürümü kullanıyor?” sorusuna net cevap vermek gerekiyor, yoksa ortalık dağılıyor; eskiden bunu tek tipe sokmak gerçekten uğraştırıyordu (kim winget kullanıyor, kim brew, kim script yazmış, kim hiç güncellememiş), şimdi işe tek komutla ilerliyorsunuz. IDP kuran ekipler için fena değil, hatta baya iş görüyor. Bu konuyla ilgili PowerToys 0.99 Çıktı: Power Display ve Grab And Move yazımıza da göz atmanızı tavsiye ederim.
Geçen ay bir sigorta şirketinde DevEx ekibiyle otururken aynı konu açıldı: 200 kişilik geliştirici grubunda tool versiyonlarını nasıl aynı çizgide tutarız? İlk akla Docker dev container geliyor, evet,. O da makineyi biraz yoruyor. Yerelde kalmak isteyenler için azd update ile birlikte bir cron job ya da scheduled task bence daha dengeli duruyor; yanı “Pazartesi sabahı 09:00’da azd update çalıştır” deyip geçebiliyorsunuz, üç satırlık PowerShell ile işi kapatmak da mümkün oluyor. Peki neden herkes böyle yapmıyor? Çünkü alışkanlık.
Küçük ekip vs büyük kurum: hangı yaklaşım?
- Tek kişilik freelance veya 2-5 kişilik startup:
azd update --channel dailyyapın. Yeni şeyleri erken görürsünüz, geri bildirim verirsiniz, bazen de bug yakalarsınız; sonra bunu GitHub’a yazarsınız, ölür biter. - 20-50 kişilik orta ölçek: Stable kanalda kalın. Ama “ayda bir Pazartesi” gıbı sabit bir gün seçin, herkes o gün
azd updateçalıştırsın; Slack’ten hatırlatma atmanız yeterli oluyor çoğu zaman. - 100+ kişilik enterprise: Group Policy ya da Intune ile zorunlu güncelleme periyodu koyun. Stable kanal mantıklı duruyor, ayda bire bağlayın; daily kanal işe sadece DevEx ekibinde test için kalsın.
Pratikte ilk gün ne yapmalı?
Aclikla söyleyeyim, bu komutu denemek için fazladan bir efor harcamaya pek gerek yok. Ama işin içine düzgün bir geçiş koyacaksanız, ben yine de su sırayı izlerim: önce mevcut sürümü görürsünüz, sonra eski kurulum yöntemini bir kez daha çalıştırırsınız, en sonda da yeni davranışı test edersiniz; hani is teoride basit, pratikte işe ufak bir detay bütün akışı bozabiliyor.
- Önce
azd versionile mevcut sürümünüze bakın. - Eğer 1.23’ten eskiyseniz, son bir kez orijinal yonteminizle (winget/brew/choco) güncelleyin.
- Tekrar
azd version— 1.23+ olduğunu teyit edin. azd updatedeneyin. “Already on latest” demesi lazım.- Bir test projesinde
azd upçalıştırın, deploy çalışıyor mu emin olun.
Bu beşinci adımı atlamayın. Ben bir keresinde bir CLI tool’unu güncelledim, terminalden komut çalışıyor gıbı görünüyordu ama içeride dependency çakışması vardı; deploy sırasında patladı, hem de tam is aceleye binmisken. O günden beri her güncellemeden sonra mini bir smoke test yapıyorum. Uc dakikalık is, sınır krizi tasarrufu sağlıyor, biraz abartı gıbı duruyor ama değil (yanlış duymadınız)
Çok konuştum, örnekle göstereyim.
Evet.
Peki neden?
Çünkü bazen sorun sürüm numarası değil, yan tarafta sessizce bekleyen bağımlılıklar oluyor. Siz ne dersiniz?
Tam da öyle.
Karşılaşabileceğiniz sorunlar (ve çözümleri)
İnanın, Şimdi dürüst olalım. Bu komut yeni, yanı ilk denemede pürüz çıkarsa çok şaşırmayın; ben de kendi tarafta birkaç kez aynı duvara tosladım.
Permission hatası: En çok da Windows tarafında, azd kullanıcı dizinine değil de Program Files altına kurulmuşsa, azd update sizden admin yetkisi isteyebiliyor. Kısa çözüm basit: Terminal’i Run as Administrator ile açın. Evet, bu kadar.
Proxy arkasında kalmak: Türkiye’deki kurumsal ortamlarda bu hikâye baya tanıdık geliyor. azd update internete çıkamıyorsa hata veriyor, o yüzden önce HTTPS_PROXY environment variable’ı set edilmiş mi bakın; sonra da işin içine kurumsal sertifika giriyorsa NODE_EXTRA_CA_CERTS ya da benzeri ayarları kontrol edin. Hani bazen sorun komutta değil, ağın kendisinde oluyor ya, işte tam o durum.
Yanı, Channel switch sonrası tuhaflık: Daily’den stable’a geçince template’ler eski alışkanlıklarını taşıyabiliyor, garip ama oluyor (ki bu çoğu kişinin gözünden kaçıyor). Böyle bir durumda azd template list --refresh çalıştırıp cache’i temizleyin. Sonra tekrar deneyin. Çoğu zaman toparlıyor.
azd‘yi CI/CD pipeline’ınızda kullanıyorsanız (örneğin GitHub Actions runner’ında), oradaki güncelleme stratejisi farklı. Pipeline’larda genelde her run’da fresh install yapılıyor, yanı açık konuşayım, çoğu senaryoda azd update‘e hiç gerek kalmıyor. Doğrudan en son sürümü install eden action’ı tercih edin; daha az uğraştırıyor.
Maliyet ve FinOps perspektifi
Şöyle ki, “Bir update komutunun maliyetle ne ilgisi var?” diye sorabilirsiniz. Haklısınız, ilk bakışta alakasız duruyor. Neyse, ama işin aslı öyle değil; eski sürümle azd kullanınca bazen yanlış SKU deploy ediyorsunuz, bazen deprecated API’ye gidiyorsunuz, bazen de gereksiz kaynak açılıyor. Bir müşterimde 1.15 sürümünde kalmış bir template vardı, sanal makineler için artık tavsiye edilmeyen bir disk tipini öneriyordu (aylık ekstra 80 dolar çıkıyordu), üstüne bunu 12 ayla çarpın, bir de 8 environment ekleyin (ilk duyduğumda inanamadım). yanı rakam ufak ufak şişiyor. SPFx Nişan 2026 Yol Haritası: Sahadan İlk Yorumlar yazımızda bu konuya da değinmiştik.
Evet. azd update sadece DX tarafında bir rahatlama değil. Dolaylı yoldan maliyet kontrolü de sağlıyor, hatta bazen fark etmeden cebinizi koruyor. Buradan bakınca finans onaylı bir “tool güncelleme politikası” çıkarmak hiç fena fikir değil. Türkiye’de TL ile düşününce durum daha da netleşiyor; kur oynayınca bu küçük tasarruflar yıl sonunda çorba gıbı karışıp ciddi bir toplam yapıyor.
İlgili gelişmeler ve genel ekosistem
Bu güncelleme tek başına bir özellik değil aslında. Microsoft’un developer tooling tarafında yürüttüğü daha geniş bir yaklaşımın parçası. Benzer mantığı son aylarda Visual Studio Mayıs Güncellemesi: Plan, İncele, İyileştir yazısında da görmüştük; orada da mesaj netti, “tool yönetimiyle oyalanma, işine bak.” Aynı çizgide GitHub Copilot’u.NET’te Verimli Kullanma Rehberi de kontekst yükünü geliştiricinin üstünden alıp araca bırakıyor, yanı işin aslı biraz da bu: insanın kafasını boşaltmak.
Durun, bir saniye.
Küçük bir detay: Bir de azd’yi sadece kendi dünyasında düşünmeyelim. Yan kuzenleri var, hatta baya kalabalıklar. kubectl, gcloud, aws CLI — bunların hepsinde self-update tarafı yıllardır var gıbı davranılıyor; AWS CLI v2 mesela aws --version dediğinizde yeni sürüm varsa haber veriyor, gcloud tarafında gcloud components update ile iş bitiyor, Azure CLI (az). az upgrade komutunu sunuyor. Demek ki azd bu konuda biraz geriden gelmişti. Evet. Ama geç olsun, güç olmasın.
Benim kanaatim
Bu özellik, kağıt üstünde küçük duruyor (ki bu çoğu kişinin gözünden kaçıyor). Günlük hayatta baya iş görüyor; hani şu “quality of life” dediğimiz şeylerden biri. AZ-400 sınavına hazırlanırken bile azd ile birkaç pratik yapmıştım — o zamanlar her makinede ayrı güncelleme komutuyla uğraşmak açık söyleyeyim can sıkıcıydı. Şimdi iş biraz daha temiz, biraz daha derli toplu.
Bir tek buraya takıldım: azd update --version 1.22.5 gıbı belirli bir sürüme dönme (downgrade ya da pin) seçeneği daha yok. Peki neden önemli? Production tarafında bazen “bir önceki sürüme dön” demek gerekiyor, çünkü sorun çıkınca ilk bakılan şey bu oluyor (özellikle acele edilen anlarda). Umarım sonraki release’de gelir; şimdilik manuel yöntemle idare etmek gerekiyor. Az önce iyi dedim ama aslında tam oturmamış tarafı da bu. Yine de doğru yöne atılmış bir adım, önü da kenara yazayım.
Bunu biraz açayım.
Sıkça Sorulan Sorular
azd update hangı sürümden itibaren çalışıyor?
Hani, Bu komut azd 1.23.x ile hayatımıza girdi. Yanı daha eski bir sürümdeyseniz, önce bir kez eski usul manuel güncelleme yapmanız gerekiyor — winget, brew, choco neyse önü kullanın. Ondan sonra artık azd update her şeyi otomatik hallediyor.
azd update ve Azure CLI’daki az upgrade aynı şey mi?
Mantık benzer ama aslında farklı tool’lar için çalışıyorlar. az upgrade klasik Azure CLI’yi, yanı o bildiğimiz az komutunu güncelliyor. azd update işe template tabanlı deployment yapan Azure Developer CLI’yi,. azd‘yi güncelliyor. İkisi de Microsoft ürünü hani, ama farklı işler yapıyorlar.
Peki neden?
Daily kanal production’da kullanılır mı?
Hani, Açıkçası tavsiye etmem. Daily kanal adından da belli — her gün build alıyor ve henüz tam test sürecinden geçmemiş özellikler içerebiliyor. Geliştirme makineleri ve test ortamları için ideal, evet. Ama production deployment’larda bence stable kanalda kalmak çok daha mantıklı.
İnternet erişimi kısıtlı kurumsal ortamda nasıl güncelleme yaparım?
Önce HTTPS_PROXY environment variable’ının doğru ayarlandığından emin olun. Proxy sertifika değiştiriyorsa kurumsal CA sertifikasını da sisteme eklemeniz gerekebilir (ben de ilk duyduğumda şaşırmıştım). Çok kısıtlı ortamlarda işe internal mirror ya da artifact repository üzerinden tedarik etmek tek seçenek olabiliyor — bu durumda maalesef azd update yerine eski yöntemde kalmanız gerekiyor.
Güncellemeden sonra mevcut projelerim etkilenir mi?
Genelde hayır. azd geriye dönük uyumluluğa önem veren bir tool. Ama tecrübeme göre büyük sürüm atlamalarında — mesela 1.15’ten 1.23’e geçiyorsanız — bazı template metadata formatları değişmiş olabiliyor. Güncelleme sonrası bir test projesinde azd up ve azd down ile kısa bir smoke test yapmanızı şiddetle öneririm.
Kaynaklar ve İleri Okuma
Azure SDK Blog: Stop juggling package managers — just run azd update
Azure Developer CLI Resmî Kurulum Dokümantasyonu
Şimdi, küçük bir detay: Azure Developer CLI GitHub Reposu (issue ve PR’lar)
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.
