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ı.

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:

1. PR açılıyor, workflow tetikleniyor
2. ./build.sh --binaryLog çalışıyor, binlog üretiliyor
3. Build başarılıysa iş bitiyor, agent uyanmıyor bile
4. Build patlarsa build-failure-analyst agent’ı devreye giriyor
5. Agent, containerized Binlog MCP Server’a bağlanıyor
6. MCP araçlarıyla binlog’u sorguluyor, kök nedeni buluyor
7. 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 Work IQ Genel Kullanıma Açılıyor: Ajanlar İçin Zeka Katmanı yazımıza bakabilirsiniz.

mcp-servers:
binlog-mcp:
container: "mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-binlog-mcp-amd64"
mounts:
— "/tmp/build.binlog:/data/build.binlog:ro"
allowed: ["*"]

Dikkat edin — mount :ro ile read-only. Yanı agent binlog’u değiştiremez (buna dikkat edin). Güzel detay. Hatta bence işin en kilit kısmı bu; çünkü prod pipeline’ında dolaşan bir agent için yetki sınırı çizmezseniz, sonra “neden böyle öldü” diye saatlerce log kazarsınız (ve genelde cevap can sıkıcı olur). Neyse uzatmayayım, güvenlik tarafı burada gayet yerinde dürüyor.

Build otomasyonunda benim genel felsefem şu: agent’a “yorum yapma” yetkisi ver, “merge etme” yetkisi verme. Advisory automation genelde actionable automation’dan daha güvenli başlangıç noktası. İnsan onayı loop’un içinde kalsın.

Aynen buna katılıyorum. İnsan faktörünü tamamen kenara itince sistem ilk gün havalı görünüyor ama sonra ufak bir sapmada saçmalamaya başlıyor; o yüzden yorumlayan agent iyi fikir, karar veren agent işe biraz fazla iddialı kalıyor bence. Peki, sız ne dersiniz?

Peki neden?

Evet.

15’ten 38’e: Yeni Araçlar Ne İş Yapıyor?

İlk yazıda tanıttığım 15 aracı çoğunuz görmüştür, hedef listesi var, hata özeti var, task detayları var,. Temel işler orada dürüyor. Peki eklenen 23 yeni araç ne yapıyor? Bak şimdi, ben en dikkat çekici olanları kendi kafamda üçe bölüp anlatayım; çünkü hepsini düz bir sıraya dizersem biraz sıkıcı olur, hem de bazıları ilk bakışta küçük görünüp sonra baya iş görüyor (en azından benim deneyimim böyle)

Derin İnceleme Araçları

Yeni gelen araçlarda en çok işime yarayacağını düşündüklerim bunlar. evaluation profiling tarafı mesela, MSBuild’in property. Item evaluation aşamasında ne kadar zaman yediğini tek tek çıkarıyor; yavaş build diye söyleniyorsanız, burada ciddi ipucu bulabiliyorsunuz. Şey. Sadece bu da değil, NuGet restore analiz araçları da eklenmiş, restore fail’leri hani bazen insanın sınırını bozar ya, hangi package hangi versiyonla çakıştı diye saatlerce kurcalarsınız (ben de yaşadım), işte o noktada baya rahatlatıyor.

Bunu biraz açayım.

Karşılaştırma Araçları

İki farklı binlog’u yan yana koyup karşılaştıran araçlar da gelmiş. Yanı “bu PR’da build dört dakika sürüyordu, şimdi 12 dakikaya çıkmış, ne değişti?” sorusunu direkt sorabiliyorsunuz; basit gibi dürüyor ama asıl mesele burada başlıyor. Çünkü performans düşüşü bir düşüneyim… bazen göze görünmüyor (özellikle küçük değişikliklerde), sonra bir bakıyorsunuz pipeline uzamış gitmiş; bu yüzden bu araç bence gizli kahraman gibi çalışıyor. Evet. Daha fazla bilgi için Headlamp Cluster API Eklentisi: CAPI Artık Görsel Arayüzde yazımıza bakabilirsiniz.

Özet ve Rapor Araçları

Bir de “insan okur” formatında özet üreten araçlar var. Yanı agent, PR yorumuna markdown biçiminde düzenli — kendi adıma konuşayım — bir rapor bırakabiliyor; tablo geliyor, madde işareti geliyor, kod bloğu geliyor… dışarıdan bakınca sade ama içeride epey kullanışlı bir akış kuruyor. Açık konuşayım, bazen teknik çıktıyı ham hâliyle görmek yetmiyor; biri önü düzgün paketleyince ekip içinde paylaşmak da kolaylaşıyor.

Enterprise vs Startup: Kim Nasıl Adapte Etmeli?

Dürüst olmak gerekirse, Şimdi asıl meseleye gelelim. Bu teknolojiyi kim, nasıl adapte etmeli? Ekip büyüklüğü burada baya belirleyici oluyor, hatta bazen işin yönünü komple değiştiriyor.

Küçük Ekip veya Startup İseniz

Baştan her şeyi kurmaya çalışmayın. İlk adım olarak bir düşüneyim… şunu yapın: build patladığında bir GitHub Action ile binlog’u artifact olarak kaydedin. Sadece bu bile iş görüyor, abartmıyorum; sonra manuel olarak Binlog MCP Server’ı VS Code’dan çalıştırıp analiz edin, çünkü AI otomasyonuna hemen atlamak zorunda değilsiniz (zaten build sıklığınız düşükse, ortada çözülecek hata hacmi de öyle devasa olmuyor).

İnanın, Evet.

Kurumsal / Enterprise İseniz

İşte burada tablo değişiyor. Günde 500+ PR alan bir monorepo düşünün; %5’i bile fail olsa günde 25 hata teşhisi demek oluyor. Her biri için 30 dakika kaybedildiğini varsayarsak, ortaya 12.5 saat/gün çıkıyor, yanı yaklaşık 1.5 tam mesai; yıllık maliyeti sız hesaplayın, ben rakamı görünce biraz duraksadım açıkçası. Daha fazla bilgi için Cosmos DB Built-in Connector for Logic Apps Standard GA Oldu yazımıza bakabilirsiniz. Git’te NTLM Kapanıyor: Azure DevOps Server İçin Kritik Uyarı yazımızda bu konuya da değinmiştik.

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.

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)

İ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:

1. Binlog üretin. Build script’inize -bl ya da --binaryLog flag’ını ekleyin. MSBuild kullanıyorsanız, msbuild /bl yazmanız yeterli. Kısa gibi dürüyor ama işin kritik kısmı burada başlıyor.
2. 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.
3. 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
4. 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.
5. Ö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

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

VS Code ile SQL Şema Yönetimi Artık Akıcı: Yayın Penceresi ve Şablonlarla Tanışın24 Mar 2026

Python Eklentisinde Mart 2026: Hız, Arama ve Küçük Sürprizler2 Nis 2026

SPFx Yol Haritası Nisan 2026: AI Özellikleri ve 1.23 RC28 Nis 2026

Microsoft Foundry Nisan 2026: Üretimde Dikkat Çeken Yenilikler17 May 2026