Geçen hafta bir müşteride başıma gelen şeyle başlayayım. Bir finans kuruluşunun DevOps ekibiyle yeni bir mikroservis yapısını Azure’a taşıyorduk; ekipte dört kişi vardı, hepsi de azd‘ye ilk kez dokunuyordu,. Işin içinde biraz merak, biraz da “bu şimdi nereden çıkacak” hali vardı. Normalde bu iş iki günü bulur, azure.yaml‘ı yazarsın, Bicep modüllerini hazırlarsın, sonra da “acaba Container Apps mı, App Service mi?” diye tartışıp durursun; ama bu sefer oturduk, yeni sürümü kurduk ve “Set up with GitHub Copilot (Preview)” seçeneğini görünce işler şaşırtıcı biçimde hızlandı. Üç saat sonra provision tamamdı.
Şimdi bakın, bu yazı reklam falan değil. Aksine, neyin işe yaradığını ve neyin hâlâ ham olduğunu olduğu gibi anlatacağım; çünkü azd tarafında iki yeni şey var ve ikisi de terminalden çıkmadan Copilot’u devreye sokuyor: biri proje iskeletini kuruyor, diğeri hata aldığında el uzatıyor. Güzel tarafları var, evet; ama insanı hafifçe kaşındıran yerleri de yok değil. Peki neden önemli? Çünkü bazen küçük görünen bir akış, bütün başlangıç süresini yarıya indiriyor.
Şimdi gelelim işin can alıcı noktasına.
Önce şunu netleştirelim: azd nedir, niye önemli?
Azure Developer CLI, yani azd, kısaca “kod yazdın, şimdi bunu Azure’a taşıyalım” aracı. Kulağa az CLI gibi geliyor, ama aynı şey değil (yanlış duymadınız). az daha çok ops tarafında duruyor; kaynak açma, kapama, script çalıştırma, otomasyon kurma gibi işlerde rahat. azd ise developer’ın masasına oturuyor. Yani “Benim bir Node.js uygulamam var, bunu Azure’a deploy etmem lazım ama Bicep bilmiyorum, Container Apps mi seçsem Function mı seçsem?” diye kafa yoran kişiye göz kırpıyor (bu konuda ikircikliyim)
Türkiye’deki şirketlerde bunu çok gördüm (ben de ilk duyduğumda şaşırmıştım). Bir ekip var, kod yazıyor; DevOps tarafında ya kimse yok ya da bir kişi otuz projeye birden bakıyor. E haliyle işler biraz sürünüyor. İşte azd tam o boşluğu doldurmak için çıkmış gibi duruyor. Copilot entegrasyonuyla birlikte artık Bicep öğrenmeden de deploy yapabiliyorsunuz — kağıt üstünde böyle. Pratikte de çoğu zaman iş görüyor ama, hani, detaylar var tabii.
Evet.
azd 1.23.11 veya üstü, aktif bir GitHub Copilot aboneliği (Individual, Business veya Enterprise) ve gh CLI gerekiyor. Sürümü kontrol etmek için azd version, güncellemek için azd update yeterli.
azd init + Copilot: Proje iskeleti kurmak artık böyle
Klasik tablo şu: Express tabanlı bir REST API’niz var, PostgreSQL’e bağlanıyor, package.json belli, src/ klasörü de toparlanmış. Bunu Azure’a taşımak istiyorsunuz. Peki nereden başlayacaksınız?
- Host tipi ne olacak? (Container Apps, App Service, Functions?) (bence en önemlisi)
azure.yamlnasıl yazılacak, hangi language/host/build ayarları doğru?- Bicep modülleri — uygulama için, veritabanı için, networking için
Bunları düzgün kurmak için dokümantasyon açıp iki saat gezinmek gerekiyor. Ya da eski bir projeden kopyala-yapıştır yapıp sonra üstünü düzeltmek. İkisi de biraz yoruyor, açık konuşayım. Copilot destekli init’te akış daha farklı:
Hmm, bunu nasıl anlatsamdı…
azd init
# Listeden "Set up with GitHub Copilot (Preview)" seç
# Copilot projeni tarar
# Önerileri sunar
# Sen onaylarsın, dosyalar yazılırCopilot ajanı dosya yapınıza bakıyor, bağımlılıkları görüyor, framework’ü kokluyor gibi davranıyor; Express + PostgreSQL kombinasyonunu yakalayınca da size Container Apps ile Azure Database for PostgreSQL tarafını öneriyor (üstüne Bicep modüllerini de ona göre hazırlıyor). Güzel tarafı şu: yazmadan önce gösteriyor (ciddiyim). Ben yine de “AI bir yerde saçmalar mı?” diye temkinliyim, o yüzden preview adımı bana baya iyi geliyor.
Ön kontroller: “git dizinim temiz mi?”
İlk denediğimde beni asıl şaşırtan şey bu oldu. Copilot işe başlamadan önce preflight check yapıyor. Yani bir yandan ortamı kontrol ediyor, bir yandan da sizi hazırlıksız yakalamıyor.
- Git working directory’n temiz mi? Commit’lenmemiş değişiklik var mı? Varsa önce uyarıyor.
- MCP (Model Context Protocol) server’ın hangi tool’lara erişeceğine dair onay istiyor.
İkinci maddeyi özellikle seviyorum. MCP üzerinden Copilot sisteminize dokunuyor; dolayısıyla “önce ne yapacağını söyle” yaklaşımı burada yerinde duruyor. Kurumsal müşterilerde en sık duyduğum soru da. Bu: “Bu AI aracı kodumuza tam olarak ne erişiyor?” Cevap net değilse işler uzuyor, hatta bazen tamamen tıkanıyor — valla güzel iş çıkarmışlar —. Burada şeffaflık var — en azından şimdilik — ve bu küçük detay bence işin bel kemiği.
“Copilot’un bu kadar ağzımdan lafı alması beni önce ürküttü, sonra rahatlattı. Çünkü yazdığı Bicep’i okuyup onaylamadan hiçbir şey diske gitmiyor. İşte bu, prodüksiyon güvenliği için kritik.”
Hata çıktığında: AI destekli troubleshooting
İnanın, Şimdi asıl yere geldik. Çünkü init kısmı tamam, ama iş azd provision ya da azd up sırasında “Deployment failed” görünce biraz can sıkıyor.
Açık konuşayım, Eski usul troubleshooting kabaca böyleydi:
- Terminal’den hatayı kopyala (bu kritik)
- Azure docs’a gir, arat (bence en önemlisi)
- Stack Overflow’a bak, benzer hata var mı diye kurcala
- GitHub Issues’ta dolaş, aynı dert başkasında da olmuş mu gör
- Yarım saat sonra “parametrem eksikmiş” ya da “role assignment yoktu” noktasına gel
Bi saniye — Yeni tarafta ise azd, hata gelir gelmez size “Copilot’a soralım mı?” diye çıkıyor. Evet derseniz, hatayı, log’u, ilgili kaynak tipini ve son yaptığınız adımları bir paket halinde Copilot’a gönderiyor; o da size ne olduğunu, neden olabileceğini ve nasıl toparlayacağınızı anlatıyor. .NET MAUI 11’de Harita Pin Kümeleme: Pratik Rehber yazımızda bu konuya da değinmiştik.
Gerçekten iş görüyor mu? Dürüst cevap.
Evet ve hayır. Açık konuşayım. Geçen ay bir telekom projesinde şunu yaşadım: Managed Identity ile Key Vault erişimi veriyorduk, deploy sırasında “Authorization failed” patladı; Copilot’a sordum, “Key Vault RBAC ayarlarını kontrol et, Key Vault Secrets User rolü eksik olabilir” dedi. Tam üstüne bastı. 15 dakika cebimde kaldı.
Ama başka bir projede — bankacılık müşterisi, networking karmaşık, private endpoint’ler var, özel DNS zone’lar dönüyor — Copilot bana “VNet entegrasyonunu kontrol et” dedi. Ettim, VNet tarafı düzgündü. Asıl mesele DNS zone’un yanlış subscription’a linklenmiş olmasıydı; bunu göremedi. Baktığı çerçeve belli bir yere kadar geliyor. Sonunda yine ben çözdüm.
Doğrusu, Kısacası: sıradan hatalarda baya iş görüyor, uçuk kaçık senaryolarda ise biraz yüzeyde kalıyor. Bu da normal bence. AI araçlarında beklentiyi doğru koymak lazım.
Ne yalan söyleyeyim, Tam da öyle.
Karşılaştırma: Copilot’lu ve Copilot’suz akış
| Aşama | Klasik azd | Copilot’lu azd |
|---|---|---|
| Proje iskeleti | Template seçersin, sonra elle kurcalarsın; açık konuşayım, bazen o iş 1-2 saati buluyor. | Kod taranıyor, öneri düşüyor, sen de hızlıca bakıp ilerliyorsun; çoğu zaman 10 dakika civarı toparlanıyor. |
| Bicep yazma | Ya manuel yazarsın ya da eski bir dosyayı kopyalarsın, yani biraz bildik usul. | Parça parça üretim geliyor, ama dur bir saniye — review yapmadan geçmek pek akıllıca olmaz. |
| Hata çözme | Docs açılır, Stack Overflow karıştırılır; bazen 30 dakika gider, bazen daha da uzar. | Bağlama göre öneri veriyor, fena değil; ama her seferinde değil, bazen 5 dakikada işi bağlıyor. |
| Öğrenme eğrisi | Bicep’i ve Azure kavramlarını didik didik öğrenmen gerekir, başka yolu pek yok. | İş akışını kavraman çoğu yerde yetiyor; hani bu da başlangıçta baya iş görüyor. |
Türkiye bağlamında: Bu özellik bize ne vaat ediyor?
İşin garibi, Kurumsal tarafta gördüğüm tablo biraz ikiye ayrılıyor. Bir taraf var, finans ve telekom gibi büyük ekipler; bunlar altyapıyı zaten DevOps ekipleriyle, IaC pipeline’larıyla, ayrı bir düzenle kuruyor. Onlar Bicep’i de biliyor, Terraform’u da. Copilot destekli init mi? Açık konuşayım, onlar için fena değil ama şart da değil. Bu konuyla ilgili Ingress’ten Gateway API’ye Geçiş: 1.0 Rehberi yazımıza da göz atmanızı tavsiye ederim.
Öbür tarafta ise startup’lar ve orta ölçekli şirketler duruyor — itiraf edeyim, beklentimin üstündeydi —. İşte asıl hareket orada. Bir arkadaşımın İstanbul’da 12 kişilik e-ticaret şirketi var, Azure’a geçiyorlar; DevOps mühendisi yok, herkes biraz kendi başına uğraşıyor, tam bu noktada Copilot destekli azd baya iş görüyor. “Bicep öğrenmem lazım” diye panik yapmadan Azure’a çıkabiliyorlar. Ben olsam bu ekibe şu sıralar bunu öneririm. Bu konuyla ilgili Kubernetes v1.36 ile Gelen Değişiklikler ve Notlarım yazımıza da göz atmanızı tavsiye ederim.
Maliyet tarafına gelince, hmm, orası da boş değil. GitHub Copilot Business kişi başı aylık yaklaşık 19 dolar; TL hesabı yapınca bugün başka yarın başka oluyor tabi. Kabaca 700-800 TL bandı diyebiliriz (ciddiyim). Bir DevOps mühendisinin saat ücretini düşününce, tek bir saatte bile zaman kazandırsa bu abonelik kendini toparlıyor (tabii bireysel planlarda son dönemde gelen kısıtları da unutmayın). GitHub Copilot Bireysel Planlarında Fren: Ne Değişti? yazısında buna değinmiştim zaten (bu konuda ikircikliyim) GitHub HTTPS’te SHA-1’i Emekliye Ayırıyor: Ne Değişecek? yazımızda bu konuya da değinmiştik.
Pratik rehber: Nereden başlayayım derseniz
Eğer daha önce hiç kurcalamadıysanız, sakin olun. İlk iş terminali açın, azd version yazın ve sürümün 1.23.11 ya da üstü olduğuna bakın; değilse azd update ile ilerleyin, çünkü eski sürümle uğraşınca insan gereksiz yere vakit kaybediyor.
- Sürüm kontrolü: Terminal açın,
azd versionyazın. 1.23.11 ve üzeri olmalı. Değilseazd update. — ciddi fark yaratıyor - Copilot aboneliğinizi doğrulayın: GitHub hesabınızda aktif olması lazım.
- gh CLI kurulumu:
gh auth statusçalıştırın, girişli değilsenizgh auth login. - Küçük bir test projesiyle başlayın: Prodüksiyon kodunda denemeyin ilk seferde. Basit bir Node.js veya Python örneği yeterli.
- Üretilen Bicep’i okuyun: Sadece “kabul et” demeyin. Neyi neden yaptığını anlayın, çünkü prodüksiyona çıktığında sizin sorumluluğunuz.
Burada gözden kaçırılmaması gereken noktalar
Birkaç uyarı var, hani gözden kaçınca sonra baş ağrıtıyor. Copilot bazen size “cool” görünen şeyi öneriyor, mesela Container Apps’e abanabiliyor. Sizin senaryoda App Service daha mantıklıysa onu seçmek gerekiyor (ben olsam ilk önce bunu sorgularım), çünkü öneri var diye her öneri doğru olmuyor.
- Copilot bazen “cool” gelsin diye Container Apps öneriyor, oysa sizin senaryonuz için App Service daha mantıklı olabilir. Önerileri sorgulayın.
- Üretilen Bicep’te hardcoded değerler çıkabiliyor — SKU’lar, region’lar, isimler. Parametrize etmek sizin işiniz.
- Güvenlik tarafında eksikler olabilir. Private endpoint, NSG kuralı, RBAC detayları… Copilot default güvenli ama “yeterince güvenli” değil. Azure DevOps Advanced Security: Tek Tıkla CodeQL Devri yazımda buna benzer bir konuya değinmiştim, bakabilirsiniz.
- MCP entegrasyonu ilginç bir yol — Azure MCP Visual Studio 2022’de: Eklenti Devri Bitti yazımda Visual Studio tarafındaki MCP’den bahsetmiştim, benzer mimari.
Evet, işin aslı bu kadar basit değil. Bir test projesinde akıyor gibi görünen şey, gerçek ortama geçince tuhaf detaylar çıkarabiliyor; o yüzden küçük başlayıp çıktıyı okumak baya iş görüyor.
İşte tam da bu noktada devreye giriyor.
Peki neden? Çünkü üretim tarafında sürpriz sevmezsiniz. Bu konuyla ilgili dönemi ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim.
Tam da öyle.
Benim yaşadığım bir hata ve çözümü
Son olarak somut bir örnek vereyim (kendi tecrübem). İlk kez azd provision çalıştırdığımda, ekranın ortasına şöyle bir hata düştü:
ERROR: failed to provision infrastructure:
deployment failed: RoleAssignmentUpdateNotPermitted:
Tenant ID, application ID, principal ID, and scope are not allowed to be updated.İşin aslı bu hata çoğu zaman, önceki bir deploy’dan kalan role assignment ile yenisinin birbirine girmesinden çıkıyor. Copilot’a sordum; bana kabaca şunu söyledi: “Önceki deployment’tan kalan orphan role assignment olabilir. Azure portal’dan subscription scope’ta principal ID’nizi aratın, eski assignment’ı silin ve tekrar provision deneyin.” Ben de aynen bunu yaptım. Düzeldi. Beş dakika sürdü. Eskiden böyle bir şey beni yarım gün oyalardı, açık konuşayım.
Sonuç: Olumlu ama temkinli
Açık konuşayım, azd ile Copilot’u yan yana koymak fena bir fikir değil. Bilhassa junior geliştiriciler ve ortada DevOps kaynağı olmayan ekipler için baya iş görüyor. Ama dur bir saniye — sihirli değnek falan da değil. Prodüksiyon kodunda gözünüzü kapatıp “Copilot halleder” derseniz, sonra uğraşırsınız; review şart, anlamak şart, sorumluluk da sizde kalıyor (ilk duyduğumda inanamadım)
İşte tam da bu noktada devreye giriyor.
Ben önümüzdeki projelerde bunu bir hızlandırıcı gibi kullanacağım. Hani şu işi — kendi adıma konuşayım — biraz çabuklaştıran araçlar var ya, işte onlardan biri. E peki, sonuç ne oldu? Ama Bicep tarafını da kenara atmam; çünkü az önce söyledim diye tamamen Copilot’a yaslanmak doğru olmaz, ikisini birlikte yürütmek daha dengeli duruyor.
Sıkça Sorulan Sorular
azd Copilot entegrasyonu için ekstra para ödüyor muyum?
Ayrı bir ücret yok. Ama aktif bir GitHub Copilot aboneliğiniz olması gerekiyor — Individual, Business veya Enterprise, hepsi çalışıyor. Azure tarafında ise yalnızca deploy ettiğiniz kaynaklar normal şekilde faturalanıyor.
Üretilen Bicep kodu prodüksiyonda kullanılabilir mi?
Size bir şey söyleyeyim, Kullanılabilir, yani ama olduğu gibi değil. Güvenlik ayarları, parametrizasyon, bir düşüneyim… isimlendirme standartları gibi konuları mutlaka gözden geçirmeniz gerekiyor. Mesela kurumsal bir ortamda naming convention’ınıza uydurmanız neredeyse kaçınılmaz. Bence en doğru yaklaşım şu: temel iskelet olarak kullanın, üstüne kendi güvenlik katmanlarınızı ekleyin.
Mevcut bir projeyi Copilot ile azd’ye nasıl taşırım?
Aslında oldukça basit. Proje dizininde azd init çalıştırıp “Set up with GitHub Copilot” seçeneğini seçmeniz yeterli. Copilot codebase’inizi tarayıp framework’ü ve bağımlılıkları algılıyor, sonra uygun Azure konfigürasyonunu öneriyor. Mevcut projenizi yeniden yapılandırmanız gerekmiyor.
Hata troubleshooting’i hangi durumlarda işe yaramıyor?
Hani, Çok özelleşmiş networking senaryolarında pek yardımcı olamıyor. Private endpoint ve DNS kaynaklı karmaşık hatalar — ki bu tartışılır — ile müşteriye özel custom policy’lerin neden olduğu durumlarda Copilot oldukça yüzeysel kalabiliyor. Açıkçası bu tür senaryolarda log’ları elle incelemek hâlâ en güvenilir yöntem.
MCP consent’i nedir, vermezsem ne olur?
Açıkçası, Model Context Protocol, hani Copilot ajanının hangi araçlara ve verilere erişebileceğini belirleyen bir onay mekanizması. Vermezseniz Copilot destekli init çalışmıyor — (en azından benim deneyimim böyle). Paniklemek yok, klasik azd init template seçimi yöntemiyle devam edebilirsiniz.
Kaynaklar ve İleri Okuma
Azure SDK Blog — GitHub Copilot meets Azure Developer CLI
Azure Developer CLI Resmi Dokümantasyonu
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.
