GitHub Rule Insights Dashboard: Kural Yönetimi Kolaylaştı

Bakın şimdi, GitHub’da ruleset (kural seti) kullanıyorsanız bilirsiniz — kurallar güzel de, “kim ne zaman bypass etti, hangi push bloklandı, neden arttı” sorularına cevap bulmak gerçekten zor oluyordu. Verilerin içinde kayboluyordunuz. Geçen ay bir finans sektöründeki müşterimizde tam olarak bunu yaşadık. Bir incident sırasında “acaba kaç kişi bypass yapmış” diye rule insights sayfasını karıştırdık, yarım saat kaybettik. Artık buna gerek yok.

GitHub, repository rulesets için yepyeni bir Rule Insights Dashboard ve birleşik filtre çubuğu (unified filter bar) yayınladı. Dürüst olmak gerekirse — kağıt üstünde basit bir iyileştirme gibi dürüyor. Pratikte platform governance tarafında ciddi bir kolaylık sağlıyor. Hani ne farkı var diyorsunuz, değil mi? Mesela büyük ekiplerde ve kurumsal yapılarda.

Rule Insights Dashboard Nedir, Ne İşe Yarar?

Önce şunu net söyleyeyim: GitHub repository rulesets, branch protection rules’un biraz daha toparlanmış, biraz da merkezileşmiş hali gibi dürüyor. Hangi branch’e kim push atabilir, force push açık mı, PR review şart mı — bunların hepsini tek yerden yönetiyorsunuz. Neyse, güzel tarafı bu. Ama işin aslı şu: Bu kuralların kaç kez devreye girdiğini, kimlerin bypass yaptığını görmek için rule insights sayfasında dolaşıp filtreleri tek tek kurmanız gerekiyordu; yanı hani iş görüyor ama insanı biraz uğraştırıyordu.

Peki neden?

Yeni dashboard işe repository’nizin Settings > Rules sekmesinde karşınıza çıkıyor. İlk açtığınızda üç temel metrik görüyorsunuz, ve açık konuşayım, ilk bakışta sade görünmesi bence iyi olmuş:

• Successes (Başarılı değerlendirmeler): Kuraldan geçen push ve PR’lar
• Failures (Başarısız olanlar): Kurallar tarafından engellenen işlemler
• Bypasses (Atlamalar): Kuralları bypass eden kullanıcıların aktiviteleri

Bunlar zamana göre bir grafik halinde geliyor. Mesela Salı günü bir incident olduysa ve push block sayısı bir anda zıpladıysa, bunu grafikte hemen görüyorsunuz. Eskiden böyle bir şeyi yakalamak için loglara dalmanız gerekiyordu, sonra biraz daha dalıyordunuz, en sonunda da “bu kadar mı?” diye kalıyordunuz. Hani bazen bir özellik çıkar ya, sessiz sakın gelir ama işi baya kolaylaştırır; işte bu da öyle.

Bir de “Most Active Bypassers” bölümü var. Hmm, burası benim gözüme daha çok battı diyebilirim. Hangi kullanıcılar en çok bypass yapıyor, liste halinde netçe görebiliyorsunuz; ayrıca herhangi bir grafiğe tıklayınca rule insights sayfasına önceden dolmuş filtrelerle gidiyorsunuz, (kendi tecrübem). Drill-down kısmı idare eder değil baya kullanışlı olmuş.

Bunu biraz açayım.

Türkiye’deki Kurumsal Yapılar İçin Neden Önemli?

Şimdi, bu özelliği “evet güzel bir dashboard” deyip geçebilirsiniz. Ama dur bir saniye — Türkiye’deki kurumsal müşterilerde gördüğüm şey biraz farklı. Mesela bankacılık ve fintech tarafında, compliance ekipleri sürekli aynı soruları soruyor: “Kim bypass yaptı? Neden yaptı? Ne zaman yaptı?” Audit trail dediğimiz mesele tam da burada devreye giriyor.

2024’ün sonlarında bir telekomda GitHub Enterprise kullanımına geçiş danışmanlığı yapıyorduk. Güvenlik ekibi bana açık açık şunu söyledi: “Biz bu bypass’ları raporlayamıyoruz, KVKK ve iç denetim için sıkıntı oluyor.” O noktada rule insights sayfasını API ile çekip Power BI’a aktardık — çalıştı, evet, ama işin aslı epey uğraştırıcıydı. Şimdi bu dashboard ile en azından görsel bir özet doğrudan GitHub içinde dürüyor. Power BI entegrasyonuna hâlâ ihtiyaç duyabilirsiniz, tabi, ama ilk bakış için baya iş görüyor.

İşte tam da bu noktada devreye giriyor.

Bypass aktivitesini izlemek sadece güvenlik meselesi değil. Aynı zamanda ekip kültürünü de ele veriyor. Sürekli bypass yapan biri varsa, ya kural yanlış tanımlanmıştır ya da o kişinin iş akışı kurallarla pek uyuşmuyordur; ikisi de ayrı ayrı bakılması gereken problemler.

Enterprise vs startup ayrımı burada da kendini gösteriyor. Küçük bir ekipseniz, 3-5 geliştiriciyle zaten kim ne yaptı az çok biliyorsunuz; soru işareti pek kalmıyor. Ama 50+ geliştirici olan bir organizasyonda bu dashboard gerçekten işe yarıyor. Startup’ta belki “ayda bir bakayım” dersiniz, kurumsal yapıda işe haftalık audit meeting’lerinde bunu ekrana yansıtırsınız. Olay bu kadar basit.

Unified Filter Bar: Neden Bu Kadar Önemli?

Gelelim ikinci büyük değişikliğe. GitHub, Şubat 2026’da filter bar tarafında bir dizi iyileştirme yapmıştı; şimdi o işi birkaç sayfaya daha yaymış. Hangi sayfalar mı? Bak şimdi, liste kısa ama etkisi fena değil.

Ne değişti diye sorarsanız, işlevsel tarafta devrim yok gibi dürüyor. Bakın, ama dur bir saniye — asıl mesele de zaten bu değil. Artık bu sayfaların hepsinde aynı filtreleme deneyimi var, custom properties desteği de eklenmiş;. Organization seviyesinde tanımladığınız özel alanlarla (mesela team, department, compliance-level) filtre çekebiliyorsunuz. Fena iş görmüyor.

Tutarlılık kısmını hafife almayın. Geçen yıl bir müşteride GitHub Advanced Security’yi açarken ekipten biri aynen şunu demişti: “Code scanning’de başka filtre var, secret scanning’de başka, insan kayboluyor.” Haklıydı da. İnsan alıştığı şeyi başka yerde de aynı şekilde görmek istiyor, hani çok basit bir beklenti gibi dürüyor ama sahada baya zaman kazandırıyor. Unified filter bar tam burada devreye giriyor.

Custom Properties ile Filtreleme

Burası önemli, çünkü çoğu kişi ilk anda gözden kaçırıyor. GitHub’da organization ya da repository seviyesinde custom properties tanımlayabiliyorsunuz; mesela bir repo’ya compliance: pci-dss veya team: backend gibi etiketler veriyorsunuz. Sonra alert dismissal ve bypass request sayfalarında bunlara göre filtre yapabiliyorsunuz. Basit gibi dürüyor, ama işin aslı günlük operasyonu epey rahatlatıyor.

İşte tam da bu noktada devreye giriyor.

Peki pratikte ne oluyor? Diyelim ki 200 repo’nuz var ve sadece PCI-DSS kapsamındaki repolarda son 30 günde kaç secret scanning bypass olmuş görmek istiyorsunuz. Unified filter bar’da custom property seçip compliance: pci-dss diyorsunuz, bitti gitti. Eskiden bunu yapmak için ya API tarafına uzanacaktınız ya da repo repo dolaşacaktınız; açık konuşayım, ikisi de biraz can sıkıcıydı. Daha fazla bilgi için VS Debugger Agent: Bug Avı Artık Ajan İşi yazımıza bakabilirsiniz.

Evet. Daha fazla bilgi için Azure MCP Araçları Visual Studio 2022’de Yerleş… yazımıza bakabilirsiniz.

Hmm, Peki Eksik Kalan Ne?

Eh, Açık konuşayım — bu güncellemeler fena değil, ama benim kafamda birkaç “ama” dönüyor.

Birincisi, dashboard hâlâ public preview aşamasında. Yanı production’da kullanılır mı? Muhtemelen evet, ama işin içinde her zaman bir iki sürpriz çıkabiliyor; ben ilk kurcaladığımda bypass grafiğindeki tarih aralığı seçimi biraz tuhaf davrandı, son 7 gün dedim ama grafik 10 günlük veri gösterdi. Belki benden kaynaklıydı, belki de bug’dı. Preview dünyası böyle zaten.

İkincisi, bu dashboard sadece repository seviyesinde dürüyor. Organization ya da enterprise tarafında toplu bir görünüm yok. 50 repo’nuz varsa, her biri için Settings > Rules sayfasına tek tek girmeniz gerekiyor; açıkçası bu, özellikle kurumsal tarafta insanın hevesini biraz kırıyor. Umarım yakında org-level bir dashboard da gelir.

Üçüncüsü… şey, burada biraz eksik kalmışlar gibi geldi bana. Notification ya da alert entegrasyonu olsa baya iş görürdü; mesela bypass sayısı şu eşiği geçerse Slack’e bildirim at gibi bir senaryo çok mantıklı olurdu. Şu an bunu istiyorsanız GitHub Actions ile bir webhook tetikleyip işi kendiniz örmeniz gerekiyor.

Pratik Kullanım Senaryoları

Incident Response Sırasında

Bir güvenlik olayı patladığında, ilk soru genelde şu oluyor: “Son 24 saatte normal dışı bir şey öldü mu?” Dashboard’daki failure grafiğine bakıyorsunuz. Spike varsa, tıklayıp içeri giriyorsunuz. Hangi kural tetiklenmiş, hangi kullanıcı etkilenmiş, hangisi sadece gürültü yapmış; hepsi orada dürüyor. Ben bunu test ettim, açık konuşayım, 2-3 dakikada eskiden 20-30 dakika süren araştırmayı çıkarabiliyorsunuz. Güzel tarafı bu. İşte, ama dur bir saniye — asıl rahatlatan şey hız değil, o karmaşık tabloyu tek ekranda toparlaması. Daha fazla bilgi için .NET 11 Preview 3: Gelen Yenilikler ve Sahadan … yazımıza bakabilirsiniz.

Haftalık Güvenlik Audit’leri

İnanın, Logosoft’ta bazı müşterilerimizle haftalık güvenlik toplantıları yapıyoruz (yanlış duymadınız). Bu toplantılarda “geçen hafta neler öldü” raporunu hazırlamak hep biraz süründürücüydü, hani insan Excel’e dönüp dönüp bakıyor ya, işte öyle. Şimdi dashboard’u açıp ekran paylaşımıyla direkt gösterebiliyorsunuz. Most active bypassers listesi de özellikle audit toplantılarında baya konuşuluyor, şaşırdım açıkçası (en azından benim deneyimim böyle). Evet. Neden önemli bu? Bir de işin garip tarafı şu: Rakamları sözlü anlatınca başka, ekranda görünce bambaşka tepki alıyorsunuz; herkes bir anda aynı noktaya odaklanıyor. Daha fazla bilgi için azd update Komutu: Paket Yöneticisi Derdine Son yazımıza bakabilirsiniz.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır. Bu konuyla ilgili .NET MAUI 11 Harita Pin Kümeleme: Sahadan Rehber yazımıza da göz atmanızı tavsiye ederim.

Kural Optimizasyonu

İnanın, Failure oranı çok yüksekse, büyük ihtimalle kurallarınız fazla sıkıdır (şaşırtıcı ama gerçek). Bypass oranı şişiyorsa, kurallar iş akışıyla pek barışmıyordur. Dashboard bu dengeyi görmenizi sağlıyor, — itiraz edebilirsiniz tabi — yanı körlemesine tahmin etmiyorsunuz. Mesela biz bir müşterimizde gördük ki — branch protection rule’u öyle sertti ki geliştiricilerin %60’ı bypass yapıyordu. Kuralı biraz gevşetince bypass oranı %10’a düştü. Tam da öyle. İşte bu tür ayarları dashboard olmadan yapmak zor; hatta bazen neden sorun yaşadığınızı bile tam anlayamıyorsunuz, sonra bir bakmışsınız mesele kuralın kendisiymiş.

Nasıl Aktifleştirirsiniz?

Aslında burada ayrı bir “açma” işi yok. Eğer GitHub’da repository rulesets kullanıyorsanız, dashboard zaten Settings > Rules altında görünmeye başlamış olmalı; public preview olduğu için bazı organizasyonlarda biraz gecikiyor, ama çoğu ortamda iş görüyor.

İlk bakışta basit dürüyor. Ama detay var.

1. Repository’nizin Settings > Rules sayfasına gidin — ciddi fark yaratıyor
2. Dashboard’un üst kısmındaki zaman aralığını “Son 30 gün” olarak ayarlayın
3. Failure ve bypass trendlerine bakın — garip bir sıçrama var mı, düşüş mü var, yoksa her şey sakın mi?
4. Most active bypassers listesini ekibinizle paylaşın — bunu es geçmeyin
5. Gerekiyorsa kural setlerinizi revize edin (bence en önemlisi)

Şöyle ki, Bazı ekipler bu ekrana bakıp geçiyor, sonra da “bir şey yokmuş” diyor. Tahmin eder mısınız? Evet, öyle değil; özellikle bypass tarafında küçük gibi duran bir hareket, ileride can sıkabiliyor (hele kurallar çok gevşekse), o yüzden listeyi sadece görmek yetmiyor, biraz da yorumlamak gerekiyor.

Ha bu arada, daha önce GitHub’daki güvenlik özelliklerini ele aldığımız GitHub Secret Scanning API. E peki, sonuç ne öldü? Webhook İyileştirmeleri yazısına da göz atmanızı öneririm — secret scanning tarafındaki bypass yönetimiyle bu dashboard birbirini tamamlıyor.

Neyse, konu dağıldı gibi öldü ama önemli bir bağlantı bu. Eğer akışta secret scanning de varsa, buradaki verilerle birlikte bakınca resim daha net çıkıyor; tek başına dashboard fena değil ama yanına o yazıdaki parçaları koyunca tablo baya oturuyor.

Ayrıca GitHub’ın deployment ve alert yönetimi tarafındaki gelişmeleri merak ediyorsanız GitHub’da Deployment Context: Repo ve Alert Yönetimi yazımız da ilginizi çekebilir.

Peki neden? Çünkü orada anlattığım repo ve alert tarafı, burada konuştuğumuz kuralların etkisini sahada daha rahat görmenizi sağlıyor; yanı sadece kural koymakla kalmıyorsunuz, neyin nerede patladığını da biraz daha net izleyebiliyorsunuz.

Maliyet ve Erişim Meselesi

Bir şeyi daha söyleyeyim. Bu özellikler GitHub Free plan’da yok. Repository rulesets zaten GitHub Pro, Team veya Enterprise planlarında çalışıyor. Türkiye’deki küçük ekipler için bu fiyat işi biraz can sıkabiliyor, hani ilk bakışta “tamam ya” diyorsunuz (ki bu çoğu kişinin gözünden kaçıyor). Sonra kur hesabı girince tablo değişiyor. GitHub Team planı kullanıcı başı aylık 4 dolar, Enterprise işe kullanıcı başı 21 dolar. Dolar kurunu da ekleyince… yanı 10 kişilik bir ekipte Team planı ayda yaklaşık 40 dolar ediyor, Enterprise tarafı işe 210 dolar civarına çıkıyor; küçük startup’lar için bu, açık konuşayım, hafif sayılmaz.

Bence küçük ekipseniz ve bütçe dar işe, önce GitHub Team planıyla yürüyün. Rulesets’i temel seviyede kullanırsınız, iş görür (en azından benim deneyimim böyle). Sonra organization seviyesinde governance ihtiyacı belirginleşirse Enterprise’a bakarsınız; yoksa sırf “olsun diye” para yakmanın pek anlamı yok. Ama 20+ geliştiricisi olan bir şirkette Enterprise plan almamak da güvenlik tarafında risk yaratıyor — bunu net söyleyeyim.

Sıkça Sorulan Sorular

Rule Insights Dashboard hangi planlarda kullanılabilir?

Aslında dashboard, GitHub repository rulesets’in olduğu her planda çalışıyor — yanı Pro, Team ve Enterprise. Free planda rulesets zaten yok, dolayısıyla dashboard da gelmiyor. Şu an public preview aşamasında, bence oldukça kullanışlı bir özellik.

Bypass yapan kullanıcıları dashboard üzerinden engelleyebilir mıyım?

Hayır, dashboard sadece görselleştirme ve raporlama için var. Bypass yetkisini kaldırmak ya da değiştirmek istiyorsan ruleset ayarlarına girip ilgili kuralı düzenlemen gerekiyor. Ama şunu söyleyeyim: dashboard üzerinden tıklayıp doğrudan o kullanıcının detay sayfasına geçebiliyorsun, bu da oldukça işe yarıyor.

Unified filter bar tüm GitHub sayfalarında mı geçerli?

Henüz değil. Şu an sadece code scanning, Dependabot ve secret scanning alert dismissal sayfalarında aktif. Zamanla diğer sayfalara da yayılacak — GitHub bu tür şeyleri zaten hep aşamalı olarak getiriyor.

Organization veya enterprise seviyesinde toplu dashboard var mı?

Şu an yalnızca repository seviyesinde bir dashboard var. Daha açık söyleyeyim, organization ya da enterprise genelinde toplu bir görünüm istiyorsan, GitHub API’sını kullanıp kendi dashboard’ünü kendin kurman gerekiyor. Açıkçası bu biraz zahmetli,. GitHub’ın yakında bu konuda bir şeyler yapması bekleniyor — kesin bir tarih yok tabii.

Dashboard verilerini dışa aktarabilir mıyım?

Dashboard üzerinden direkt CSV veya Excel export yok maalesef. Ama tecrübeme göre en iyi yol şu: rule insights verilerine GitHub REST API üzerinden erişip istediğin formatta çekebiliyorsun. Mesela Power BI veya Grafana entegrasyonu kurmak istiyorsan API zaten tercih edilen yöntem.

Kaynaklar ve İleri Okuma

Rule insights dashboard and unified filter bar — GitHub Blog

About repository rulesets — GitHub Docs

Managing rulesets for a repository — GitHub Docs

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

.NET Agent Skills: Üç Yöntem, Tek Sağlayıcı13 Nis 2026

PHP 8.5 Azure App Service'te: Ne Değişti?12 Nis 2026

GPT-5.1 Codex Modelleri Emekli Oldu: Ne Yapmalısınız?4 Nis 2026

Gece Yarısı Çöken Donanım: WinForms ve AI Bir Anneye Nasıl Can Simidi Oldu?21 Mar 2026