GitHub Copilot ile azd: Terminalde Akıllı Kurulum, Hızlı Çözüm
Geçen hafta bir müşteride, İstanbul’daki küçük. Hızlı büyüyen bir SaaS ekibinde, tam da şu sahneyi yaşadık: proje ayağa kalkacak ama ekipte kimse “hangi Azure servisi hangi iş için daha doğru” sorusuna saatler harcamak istemiyor. İşte azd ile GitHub Copilot entegrasyonu burada bayağı işe yarıyor. Klasik kurulumda insan önce dokümantasyona dalıyor, sonra Bicep tarafında ufak bir detay kaçıyor, ardından terminalde hata üstüne hata… derken gün bitiyor.
Vallahi, Yeni akışın hoşuma giden tarafı şu: seni tarayıcıya atıp bırakmıyor. Terminalin içinde kalıyorsun. Bence bu küçük gibi görünen şey büyük fark yaratıyor; çünkü bağlam kopmuyor. Bilhassa kurumsal tarafta, Azure DevOps. GitHub arasında gidip gelen ekiplerde bu tür “sürtünme azaltan” deneyimler çok kıymetli oluyor.
Bu yazıda işi sadece “Copilot geldi, ne güzel” seviyesinde bırakmayacağım. Bir de şunu söyleyeyim: kağıt üstünde fena değil, pratikte işe bazı yerlerde çok iyi, bazı yerlerde hâlâ ham. Mesela güvenlik. Ön onay adımları güzel düşünülmüş ama her projede aynı derecede kusursuz çalışır demek biraz fazla iyimser olur. Neyse uzatmayalım; gelin olaya hem teknik hem de saha gözlüğüyle bakalım.
Neden Bu Entegrasyon Dikkat Çekiyor?
Peki neden? Asıl mesele hızdan ibaret değil. Yeni başlayan bir proje için doğru iskeleti çabuk kurmak istiyorsunuz, mevcut bir uygulamayı Azure’a taşırken de baştaki belirsizliği azaltmak istiyorsunuz; ben bunu 2019’da Ankara’da bir finans projesinde manuel Bicep yerine ARM template’lerle denerken fazlasıyla hissetmiştim (ekipte iki kişi Azure biliyordu, diğerleri uygulama katmanına gömülmüştü), o zamanlar “keşke yapı kendi kendine biraz anlasaydı” diye iç geçirmiştik.
azd init içinden gelen Copilot seçeneği, projeyi analiz edip sana uygun azure.yaml, altyapı dosyaları. Dağıtım ayarlarını öneriyor. Yanı sıfırdan başlarken de var olan projeyi taşırken de aynı mantıkla ilerliyor: kod tabanına bak, teknoloji yığınını çıkar, buna göre yol çiz. Açık konuşayım, özellikle Express.js + PostgreSQL gibi kombinasyonlarda bu yaklaşım baya iş görüyor.
Şimdi gelelim işin can alıcı noktasına.
Ha bu arada, buradaki değer sadece üretmek değil; yanlış üretimi erken yakalamak da önemli. Preflight kontrolleri sayesinde çalışma dizini temiz mi diye bakılıyor, MCP sunucu izinleri baştan soruluyor. Bu iyi haber çünkü kurumsalda en sık gördüğüm sorunlardan biri şu: araçlar fazla güçleniyor (inanın bana). Yetki sınırları sonradan düşünülüyor. Sonra bir bakmışsın herkesin eriştiği yere yanlışlıkla yarım konfigürasyon yazılmış… hoş değil.
Bunu Türkiye’deki şirketler açısından değerlendirirsek iş biraz daha kritik hâle geliyor. Çünkü bizde çoğu ekip hem maliyet baskısı altında hem de insan kaynağı sınırlı çalışıyor. Küçük ekipler için azd + Copilot kombinasyonu ciddi hız kazandırabilir; enterprise tarafta işe bunun yanına onay süreçleri, policy set’leri ve merkezî güvenlik denetimleri eklenmeli. Yoksa hızlı başlarsın ama kontrolü kaybedersin — klasik hikâye.
Kurulum Akışı Nasıl İşliyor?
Süreç basit görünüyor ama detayları önemli. Önce azd version ile sürümü kontrol ediyorsun; 1.23.11 ve üzeri gerekiyor. Sonra GitHub Copilot aboneliğin aktif olmalı ve gerekiyorsa gh oturumu açılıyor. İlk bakışta sıradan gibi dürüyor fakat pratikte sürüm uyuşmazlığı ya da giriş problemi yüzünden patlayan senaryoları ben birkaç kez gördüm.
Bir müşteri ortamında — İzmir’deki bir üretim firmasındaydı — ilk denemede komutun sessizce takıldığı öldü çünkü CLI eskiydi ve kullanıcı hesabında GitHub oturumu yoktu. Bu ne anlama geliyor? Hata mesajı çok net değildi; hatta ilk anda sanki ağ problemi varmış gibi görünüyordu! Çözüm basitti: önce güncel sürüme geçtik, sonra kimlik doğrulamayı düzeltince akış yürüdü (inanın bana) Daha fazla bilgi için Visual Studio 2026’da C++ İçin Sessiz Devrim: Hız, Copilot ve PGO yazımıza bakabilirsiniz.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Copilot burada sihir yapmıyor; mevcut kodu okuyup mantıklı varsayımlar üretiyor.
O yüzden sonuçları “otomatik doğru” diye görmek yerine büyük ihtimalle incelemek gerekiyor.
Size bir şey söyleyeyim, Preflight check, MCP consent, proje analizi. Çıktıların onaya sunulması aslında zincirin sağlıklı halkaları gibi çalışıyor. Bunu mutfakta yemek yapmak gibi düşünün: malzemeler hazır mı bakmadan tencereyi ocağa koyarsanız sonunda tatsız bir şey çıkar. Burada da aynı durum var; hazırlık aşaması kısa sürüyor ama işi kurtarıyor. Bu konuyla ilgili Dependabot artık sbt’yi görüyor: Java ekosisteminde küçük ama etkili değişim yazımıza da göz atmanızı tavsiye ederim.
Kod bloğuyla kaba akış
azd version
azd init
# Select: "Set up with GitHub Copilot (Preview)"
azd provision
azd upKod Tabanını Okuyup İskelet Çıkarması Neyi Değiştiriyor?
Bana göre asıl kırılma burada oluyor.
Eskiden yeni proje kurulurken framework seçimi ayrı dertti, hosting modeli ayrı dertti, veritabanı ayrı dertti.
Şimdi Copilot proje yapısını okuyup sana uygun başlangıç önerisi verebiliyor.
Mesela Express API varsa Container Apps mantıklı olabilir; Function App her zaman doğru seçim değildir.
İşte bu ayrımı hızlı yapmak önemli.
Evet, doğru duydunuz. Bu konuyla ilgili SharePoint Framework 1.23 ve Ötesi: Asıl Mesaj Ne? yazımıza da göz atmanızı tavsiye ederim.
Bunun artısı kadar eksisi de var tabi.
Eğer repo karmaşıksa veya alışılmadık bağımlılıklar içeriyorsa model yanlış tahmin yapabilir.
Ben geçen ay Eylül 2025’te Logosoft’ta bir demo ortamında bunu test ederken monorepo yapısında ufak karışıklık yaşadım;
Copilot ana servisi doğru gördü ama yardımcı paketi gereğinden fazla önemsedi.
Yanı çıktı iyi idi ama %100 final karar vermeyecek kadar da hamdı.
Eğer bütçeniz kısıtlıysa ya da ekip Azure konusunda yeni işe bu özellik bayağı iş görüyor.
Ama düzenli platform ekibi olan enterprise yapılarda ben yine de altın kuralı değiştiriyorum:
önce kurum standardını tanımla,
sonra AI’ın önerisini onun içine şok.
Yoksa herkes kendi doğrusu ile ilerler… sonrasında bakım maliyeti yükselir.
| Konu | Klasik Yol | Copilot + azd |
|---|---|---|
| Başlangıç süresi | Daha uzun | Daha kısa |
| Tutarlılık | Ekip bilgisine bağlı | Daha yönlendirilmiş |
| Sahiplenme riski | Düşük-orta risk görünürlükte olur | Onay yoksa risk artar |
| Maliyet etkisi | Zaman maliyeti yüksek olabilir | Lisans + işlem zamanı dengelenmeli |
Error Troubleshooting Tarafı Neden Daha İlginç?
Dürüst olmak gerekirse, Açık konuşayım, beni en çok burası heyecanlandırdı.
Çünkü dağıtım hatası çıktığında çoğu ekip panik yapıyor:
logu kopyala,
Google’a yapıştır,
Stack Overflow’da gez,
birkaç dakika sonra başka sekmeye geç…
Arada geçen sürede konsantrasyon dağılıyor.
Copilot’un terminal içindeki troubleshooting yaklaşımı bunu biraz toparlıyor. Bu konuyla ilgili GitHub Copilot’ta.NET İşini Doğru Yerden Tutmak yazımıza da göz atmanızı tavsiye ederim.
Mesele şu ki hata mesajları çoğu zaman doğrudan çözümü söylemez.
Eksik parametre mi var?
Yetki mi yok?
Kaynak adı mı çakıştı?
Ya da network policy mi engelliyor?
Copilot bu parçaları yorumlayıp daha makul bir açıklama getirebiliyor.
Tabiî bazen beklediğim kadar iyi olmuyor;
özellikle karmaşık RBAC senaryolarında daha dikkatli olmak şart. Bu konuyla ilgili copilot konusundaki yazımız yazımıza da göz atmanızı tavsiye ederim.
Bakın, Mart 2024’te İstanbul’daki bir telekom müşterisinde benzer şekilde azd provision başarısız olmuştu.
İlk hata mesajı kafa karıştırıcıydı çünkü olay aslında yanlış subscription seçilmesiydi;
Copilot öneriyi ilk turda tam vuramadı. Log okuma süresini ciddi azalttı.
Aslında — hayır dur, daha doğrusu dur — şöyle anlatayım:
bu araç sorunu sizin yerinize çözmüyor,
ama sorunun etrafındaki sis perdesini inceltiyor.
Dikkat edilmesi gerekenler listesi
- Sürümleri kontrol etmeden başlamayın.
- MCP izinlerini rastgele açmayın.
- Copilot önerisini direkt prod’a taşımayın.
- Büyük kurumlarda standart landing zone dışına çıkmayın. (bu kritik)
- Eğer repo kirliyse önce temizleyin; preflight boşuna değildir!
Kendi Pratiğimden Üç Net Not Alt Yapıda Hız Kazandırır mı?
İnanın, Evet kazanır.
Ama her yerde değil.
En faydalı olduğu alanlar genelde tekrarlı başlangıç işleri. Bariz hata teşhisleri oluyor.
AZ-305’e hazırlanırken bile benzer şeyi görmüştüm: mimarı kararların yarısı teknik bilgiyle verilirken kalan yarısı bağlam bilgisiyle geliyor.
AI burada bağlam bilgisini destekleyebilir ama bayağı devralamaz (kendi tecrübem)
Nisan 2026’da Logosoft’ta yaptığımız iç değerlendirmede şunu not ettim:
Küçük ürün takımlarında adoption daha hızlı oluyor çünkü karar döngüsü kısa;
kurumsal yapılarda işe güvenlik ekibi devreye girdiği anda işler yavaşlıyor ama doğrusu da bu zaten.
Bence bu doğru yönde atılmış bir adım,
yalnız hâlâ eksik olan şey “kurum politikasıyla hizalama” kısmının daha görünür olmasıdır.”
Nereden başlamalı?
,
- …
- `azd` sürümünü yükseltin and login kontrollerini yapın;
- Kritik olmayan bir repoda deneyin; — bunu es geçmeyin
- Copilot çıktısını manuel gözden geçirin;
- Pilotu prod’a almadan önce policy kontrolü koyun; — bunu es geçmeyin
- Eğer maliyet hassassa Container Apps ile App Service’i kıyaslayın…
>
Sıkça Sorulan Sorular
Ne Kadar Hazır Geliyor?
Copilot `azd init` sırasında tam olarak ne yapıyor?
Açıkçası, Kod tabanınızı analiz edip uygun azure.yaml, altyapı dosyaları ve dağıtım ayarlarını öneriyor.
Yanı aslında elle başlayacağınız temel iskeleti ciddi biçimde hızlandırıyor — bence bu en büyük artısı.
Ama sonucu mutlaka gözden geçirmek gerekiyor, körü körüne güvenmemek lazım.
Bunu kullanmak için ücretli GitHub Copilot şart mı?
Ne yalan söyleyeyim, Evet, şart.
Aktif bir GitHub Copilot aboneliğine ihtiyacınız var.
Individual, Business veya Enterprise planlarından biri yeterli olabiliyor ama detayı kendi tenant/hesabınıza göre kontrol etmenizi öneririm.
Hani lisans erişimi olmadan akış zaten başlamıyor.
Büyük kurumlarda kullanmaya uygun mu?
Uygun, evet.
Ama tek başına bırakılırsa risk doğurabiliyor.
Tecrübeme göre büyük organizasyonlarda bunu ancak onay süreçleri, MCP yetkilendirme sınırları ve standart şablonlarla birlikte kullandığınızda gerçekten anlamlı hâle geliyor.
Yoksa hız kazanırsınız ama yönetilebilirlik düşer — açıkçası bu dengeyi kurmak kritik.
Troubleshooting tarafı gerçekten işe yarıyor mu?
Yarıyor, özellikle sık karşılaşılan deployment hatalarında oldukça faydalı oluyor. Ama RBAC, network policy veya özel platform bağımlılıklarında bazen yeterince derine inemeyebiliyor. Yanı yardım ediyor, kurtarıcı rolünde değil — beklentiyi buna göre ayarlamak gerekiyor.
Kaynaklar ve İleri Okuma
Azure Developer CLI Resmî Dokümantasyonu
GitHub Copilot Resmî Sayfası
Azure Architecture Center
İlgili yazılar için:
Copilot kullanımında yeni dönem: Cohort verisi ne anlatıyor?
Azure DevOps MCP Server Nisan Güncellemesi: Küçük Dokunuşlar, Büyük Etki
MCP Apps Copilot Chat’te İş Akışları Artık Konuşmanın İçinde
(en azından benim deneyimim böyle)
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.
Yorum gönder