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.
- Önce mevcut versiyonunuzu kontrol edin:
azd version - 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
- 1.23.x veya üzerindeyseniz, artık
azd updateyeterli - İlk defa kuruyorsanız:
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 updatekoş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 versionBu 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 upgradevardı, şimdiazdtarafı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ünaz tool update --allgibi 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 loginile 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 bildirım 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 upgradeAzure CLI’ı (az) güncellerken,azd updateAzure 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
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.
3 comments