Binlog MCP Server: CI’da Otomatik Build Analizi Devri
Şöyle bir sahne düşünün: Cumartesi sabahı, kahveyi yeni demlemişsiniz, telefon çalıyor. Ekipten biri “Abi build patladı, PR’ı merge edemiyoruz, senin bakman lazım” diyor. Klasik hikâye. Binlog dosyasını indir, Structured Log Viewer’da aç, hangi target dağıtmış bir bak, hangi task fail olmuş, MSBuild çıktısını satır satır oku… Bazen yarım gün gidiyor, açık konuşayım.
İşte Microsoft’un geçen yıl duyurduğu Binlog MCP Server tam bu dert için çıktı. İlk yazılarda interaktif kullanımı gösterdiler — yanı sen bilgisayarın başında oluyorsun, AI asistana “şu binlog’a bak” diyorsun, o da sana anlatıyor. Güzel tarafı bu. Ama dur bir saniye — işin asıl ilginç kısmı şimdi geliyor: aynı MCP araçlarının kimse başında olmadan, CI pipeline’ının içinde çalışması.
Bir dakika — bununla bitmedi.
Tuhaf ama, Dün akşam microsoft/testfx reposunda bunun canlı örneğine denk geldim. PR açılıyor, build (söylemesi ayıp) patlıyor, birkaç dakika sonra PR’a otomatik yorum düşüyor: “Şu target’ta şu task fail öldü, kök neden bu gibi dürüyor, şöyle düzeltebilirsin.” Kimse binlog indirmiyor. Kimse Structured Log Viewer açmıyor. Junior geliştiriciler de build uzmanını beklemiyor; fena değil yanı (ciddiyim)
Neden Bu Konu Aslında Sandığınızdan Daha Önemli?
Açık konuşayım: build hatası analizi neredeyse hiç “seksi” bir konu olmadı. Kimse konferansta bunu anlatmak istemez. Ama sahada iş değişiyor,. Kurumsal ekiplerde build patladığında ortalama 30-90 dakika gidiyor; bunu kişi bazında yıl sonuna vurunca, rakam bir anda tatsızlaşıyor.
Bunu biraz açayım.
Hani şu meşhur “build wizard” figürü var ya, her ekipte bir tane çıkar: build patlayınca herkes ona koşar. O da 20 senedir MSBuild’in derinliklerinde yüzdüğü için 5 dakikada çözer,. O kişi izne çıkınca ekibin yarısı afallıyor; bilgi tek kişide kilitli kalınca, işte klasik bus factor problemi tam oradan başlıyor.
Kendi deneyimimden konuşuyorum, MCP ile CI entegrasyonu tam da bunu adresliyor (ben de ilk duyduğumda şaşırmıştım). Build patlaması artık “bilene sor” meselesi olmaktan çıkıyor, “bota sor, PR yorumunda cevap gelsin” tarafına kayıyor. Ha, mükemmel mi? Hayır. Bazen bot da yanılıyor, bazen kök nedeni tam bulamıyor; ama ilk teşhis için baya iş görüyor. Doktora gitmeden önceki triyaj gibi düşünün.
MCP Nedir, Kısaca Hatırlatayım
Model Context Protocol, Anthropic’in ortaya attığı bir standart (ciddiyim). İşin özü şu: AI modelleri (Claude, GPT, ne kullanıyorsanız) dış dünyayla konuşurken herkes kendi garip API’sını yazmasın, ortak bir dil olsun. Bir MCP sunucusu bazı “araçlar” (tools) sunuyor, AI istemci de bunları çağırıyor. Sohbetin ortasında model “Ben binlog’u okumalıyım” diyor, sonra MCP çağrısı gidiyor, sonuç da geri geliyor.
Bi saniye — Bak şimdi, kulağa basit geliyor (ben de ilk duyduğumda şaşırmıştım). Pratikte baya iş görüyor; çünkü entegrasyon tarafında her seferinde sıfırdan bağlantı kurma derdi azalıyor (özellikle tool sayısı artınca bu fark daha net çıkıyor), bir noktadan sonra ekipler aynı mantığı tekrar tekrar yazmaktan kurtuluyor. Evet.
Binlog MCP Server da tam olarak bunu yapıyor — MSBuild’in ürettiği o meşhur .binlog dosyalarını okuyup içindeki bilgileri araç çağrıları üzerinden AI’a sunuyor. İlk sürümde 15 araç vardı, şimdi 38’e çıkmış; aradaki 23 yeni araç da boşuna eklenmemiş gibi dürüyor, yanı olgunlaşma var. Biraz da “tamam artık bu iş oturuyor” hissi veriyor.
Türkiye’deki Ekipler İçin Ne Anlama Geliyor?
Şunu söyleyeyim, Bunu bizim taraftan düşünürsek — pek çok kurumsal.NET ekibi hâlâ Azure DevOps Server’da (eski TFS) ya da self-hosted Jenkins’te build alıyor; GitHub Actions her yerde yok, hatta bazı ekiplerde hiç gündeme bile gelmiyor. Ama güzel tarafı şu: Binlog MCP Server’ın container imajı public, mount edip herhangi bir CI içinde çalıştırabiliyorsunuz. GitHub Actions’a mecbur değilsiniz; Azure Pipelines olur, GitLab CI olur, Jenkins scriptleri olur — itiraf edeyim, beklentimin üstündeydi —
Bakın, Şey var bir de: Türkiye’de KVKK ve veri egemenliği hassasiyeti olan kurumlar için kilit nokta şu — bankalar, kamu ve sağlık tarafında binlog dosyanız hiçbir yere uçmuyor. Container’a read-only mount ediliyor (yanı dosya yerinde kalıyor), LLM çağrısı yapılırken sadece ilgili özet gidiyor (en azından benim deneyimim böyle). Açık konuşayım, binlog’u internete yüklemek gibi bir durum yok burada; bu da veri sızıntısı konusunda tedirgin olan ekipler için rahatlatıcı oluyor.
Peki neden? Çünkü log dosyasını komple dışarı taşımak yerine sadece ihtiyaç kadar bilgi paylaşmak daha güvenli hissettiriyor; ayrıca debug ederken de elinizde ham veri kalmaya devam ediyor. Tam da öyle.
GitHub Actions’ta Bu İşin Anatomisi
Microsoft’un testfx reposundaki örnek workflow’u açtım, adı da build-failure-analysis.md. İlk bakışta biraz garip geliyor (en azından benim deneyimim böyle). Workflow YAML değil, Markdown içinde dürüyor; sonra gh aw denen araç bunu .lock.yml‘a compile ediyor. GitHub Agentic Workflows dedikleri şey de tam burada devreye giriyor, yanı işin aslı biraz alıştığımız GitHub Actions düzeninden kayıyor.
Peki neden böyle yapmışlar? Bence sebep basit: akışı daha okunur tutmak istiyorlar, ama dur bir saniye — bu okunurluk bazen insanı kandırabiliyor, çünkü altta yine ciddi bir otomasyon var ve o otomasyon yanlış kurgulanırsa küçük bir PR bile gereksiz yere büyüyebiliyor. Yine de fikir fena değil.
Şimdi gelelim işin can alıcı noktasına.
İş akışı kabaca şöyle dönüyor:
- PR açılıyor, workflow tetikleniyor
./build.sh --binaryLogçalışıyor, binlog üretiliyor- Build başarılıysa iş bitiyor, agent uyanmıyor bile
- Build patlarsa
build-failure-analystagent’ı devreye giriyor - Agent, containerized Binlog MCP Server’a bağlanıyor
- MCP araçlarıyla binlog’u sorguluyor, kök nedeni buluyor
- PR’a otomatik yorum düşürüyor
Yanı, Burası hoşuma gitti. Şey gibi: önce sistemi yormuyorsun, sonra sadece sorun varsa zekayı çağırıyorsun. Ama açık konuşayım, bu yaklaşımın güzel tarafı kadar ince bir tarafı da var; çünkü agent’ın neyi okuyup neyi yazabildiği net olmazsa, otomasyon kısa sürede “yardımcı” olmaktan çıkıp baş ağrısına dönüşebiliyor.
MCP sunucusunun tanımı da bayağı temiz: Daha fazla bilgi için
Enterprise için benim önerim şu: advisory mode’da başlayın. Yanı agent sadece yorum yazsın, hiçbir aksiyon almasın; 2-3 ay gözlemleyin, kök neden isabet oranı %80’i geçince ikinci fazda “otomatik retry” gibi düşük riskli aksiyonlar tanımlayın (mesela flaky test detection), ama dur bir saniye — bunu da her repoya aynı şekilde yaymayın, önce dar alanda deneyin.
az repos pr comment ile PR’a düşürebilirsiniz. Aynı fikir, farklı sos.Maliyet Hesabı: LLM Faturası Ne Kadar Tutar?
Bu konuya pek giren yok, ama bence kritik. Her build fail’inde bir LLM çağrısı yapıyorsanız, faturayı hesaba katın; çünkü binlog’lar bazen gerçekten şişiyor (yüzlerce MB oluyor), ama akıllı bir MCP tasarımıyla tamamı LLM’e gitmiyor, sadece agent’ın sorduğu özet parçalar gidiyor (inanın bana)
| Senaryo | Günlük Fail Sayısı | Tahmini Aylık LLM Maliyeti |
|---|---|---|
| Küçük ekip | 2-5 | ~15-40 USD |
| Orta ölçek | 20-30 | ~150-300 USD |
| Enterprise monorepo | 100+ | ~800-1500 USD |
İtiraf edeyim, Bu rakamlar Claude Sonnet ya da GPT-4 sınıfı modeller için kaba bir çerçeve, yanı taş çatlasın bu kadar diyelim (inanın bana). Daha küçük modellerle (mesela GPT-4o-mini) koşarsanız maliyet yarıya inebiliyor, hatta bazı senaryolarda daha da aşağı düşüyor; ama işin tuhaf tarafı şu — bir junior developer’ın tek bir saatlik zamanı bile çoğu zaman bu faturadan pahalıya geliyor.
Evet.
Pratik Uygulama Rehberi: İlk Adımlar
Merak edip denemek isterseniz, işi çok büyütmeden sırayla şu adımları izleyin:
- Binlog üretin. Build script’inize
-blya da--binaryLogflag’ını ekleyin. MSBuild kullanıyorsanız,msbuild /blyazmanız yeterli. Kısa gibi dürüyor ama işin kritik kısmı burada başlıyor. - Yerelde deneyin. VS Code ile GitHub Copilot Chat’i açın, Binlog MCP Server’ı lokal çalıştırın ve bir fail olmuş binlog dosyası verip “kök neden ne?” diye sorun. İlk cevapta tam oturmayabilir, normal; ben olsam burada biraz kurcalarım.
- Sonuçları değerlendirin. 10-15 gerçek fail üstünde test yapın. Bot kaçını doğru buldu, hangi tiplerde tökezledi, hangilerinde işe şaşırttı açıkçası; bunları not edin. Peki neden? Çünkü ilk izlenim bazen yanıltıyor. — bunu es geçmeyin
- CI’a taşıyın. Başarı oranı tatmin ediciyse container’ı CI pipeline’ınıza alın. Advisory mode ile başlamak bence daha akıllıca, çünkü önce izlemeniz lazım; sonra isterseniz sıkarsınız ayarları. Evet.
- Ölçün. “Mean Time To Diagnosis” (MTTD) metriğini takip edin. Bot devreye girdikten sonra süre düşüyor mu, yoksa aynı yerde mi patinaj yapıyor; asıl bakmanız gereken yer burası. Bu kadar mı? Değil tabiî.
Bu konuyla bağlantılı olarak, CI/CD pipeline mimarisi genel anlamda son 2 yılda AI-native bir yöne kayıyor; yanı sadece otomasyon değil, biraz da karar verme katmanı ekleniyor işin içine. Bizim daha önce yazdığımız VSIX Yayınını GitHub Actions’a Devretmek: Sade. Tekrar Edilebilir Bir Yol yazısıyla birlikte okursanız, GitHub Actions’ın modern.NET ekosisteminde nereye doğru evrildiğini daha net görürsünüz (ben açık konuşayım, tablo baya değişti). Bir de bu tarz agentic yaklaşımların Azure DevOps tarafındaki karşılığı için Copilot Code Review Azure Repos’a Geldi: Sahadan İlk İzlenimler yazısı da iyi bir tamamlayıcı oluyor; orada da benzer bir kırılma var aslında, sadece başka taraftan bakıyoruz.
Neyse, çok dağıttım, konumuza dönelim. Sız ne dersiniz?
Bakın, Tam da öyle.
Kısıtlar ve Beklenti Yönetimi
Yanı, Şimdi biraz frene basalım. Bu iş her derdin ilacı değil, öyle uzaktan bakınca parlayan şeylerden biri gibi dürüyor ama içeride birkaç net kısıt var.
Birincisi, çok karmaşık transitive dependency hatalarında bot bazen yüzeyde kalıyor. “NuGet restore fail” diye işaret ediyor, tamam, peki hangi paket patlamış, hangi transitive hangi versiyonla çakışmış — işte orada biraz tökezleyebiliyor; kompleks vakalarda insan eli hâlâ lazım oluyor.
Evet.
İkincisi, custom MSBuild target’ları olan projelerde bot biraz yabancılaşıyor. Standart.NET SDK build’lerinde fena değil ama bir kurumun 10 senedir biriktirdiği garip.targets dosyalarını okurken bazen duvara tosluyor; açık konuşayım, bu da çok şaşırtıcı değil çünkü model o dosyaları daha önce görmemiş olabiliyor.
Üçüncüsü — ve burası bence en can sıkıcı taraf — false confidence (ki bu çoğu kişinin gözünden kaçıyor). Bot bazen öyle kendinden emin konuşuyor ki, yanlış kök nedeni sanki kesinmiş gibi söylüyor; junior bir geliştirici de bunu okuyup peşine düşerse yarım gününü yanlış yolda harcayabiliyor,. Ekip içinde “bot her zaman haklı değildir” refleksini yerleştirmek şart.
Durun, bir saniye.
Sıkça Sorulan Sorular
Binlog MCP Server’ı Azure DevOps Server (on-prem) üzerinde çalıştırabilir mıyım?
Doğrusu, Evet, çalıştırabilirsiniz. MCP Server bir Docker container olarak dağıtılıyor. Azure DevOps Server’ın pipeline agent’ında Docker desteği varsa — self-hosted agent önerilir aslında — container’ı çalıştırıp binlog’u mount edebilirsiniz. İşte, gitHub Agentic Workflows sözdizimi çalışmıyor, ama benzer akışı klasik pipeline task’larıyla da kurabilirsiniz, hani çok takılmaya gerek yok buna.
LLM olarak Azure OpenAI kullanabilir mıyım, illâ OpenAI/Anthropic mi olmalı?
Bence Azure OpenAI kullanabilirsiniz. MCP client tarafı hangi modeli çağırdığınızdan bağımsız çalışıyor. Açıkçası kurumsal ortamda veri egemenliği için. Azure OpenAI çok daha uygun — endpoint’ınız Türkiye veya AB region’ında olabiliyor, veriler dışarı çıkmıyor. GPT-4o veya GPT-4.1 model deployment’ı yapıp Copilot Chat’i o modele yönlendirebilirsiniz, yanı ekstra bir engel yok.
Bot’un yanlış kök neden bulma oranı nedir?
Microsoft’un yayınladığı değerlendirme verilerine göre standart.NET SDK projelerinde %80+ isabet oranı görülüyor (ciddiyim). Bence fena değil. Custom build sistemleri veya karmaşık MSBuild extension’ları olan projelerde bu oran %60’lara kadar düşebiliyor. Tecrübeme göre kesin rakamı öğrenmek için kendi repolarınızda 15-20 fail örneğiyle test etmek en sağlıklısı.
Binlog dosyaları güvenlik açısından risk oluşturur mu?
Oluşturabilir. Binlog’lar bazen build sırasında environment variable’ları, secret’lar veya iç path bilgileri içerebiliyor. Bu yüzden binlog’u dışarı göndermeden önce redaction yapmak iyi bir pratik — bence bu adımı atlamayın. MSBuild’in -p:MSBuildTreatWarningsAsErrors ve secret masking özelliklerini birlikte kullanın. Bir de şunu belirteyim: MCP çağrıları LLM’e binlog’un tamamını değil, sadece query sonuçlarını gönderiyor,. Bu da doğal bir koruma katmanı sağlıyor aslında.
Bu sadece.NET için mi, yoksa Java/Node.js build’leri için de var mı?
Bakın, binlog MCP Server spesifik olarak MSBuild binary log formatı için tasarlanmış. Java (Maven/Gradle) veya Node.js tarafında henüz eşdeğeri yok. Ama MCP protokolü açık standart olduğu için benzerlerinin çıkması sadece zaman meselesi — genel bir “build analysis MCP” için topluluk çalışmaları başladı mesela, takip etmenizi öneririm.
Kaynaklar ve İleri Okuma
MCP Beyond the Chat Window: Build Diagnostics in CI (.NET Blog)
microsoft/testfx GitHub Reposu — Örnek Workflow’lar
Model Context Protocol Resmî Dokümantasyonu
MSBuild Binary Log 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.
3 comments