GitHub Code Quality API: Repo Bazlı Açma-Kapama Dönemi
Kendi deneyimimden konuşuyorum, Geçen hafta bir müşteride tam da şu soru açıldı: “Her repoya tek tek girip Code Quality açmak zorunda mıyız?” Açık konuşayım, kurumsal tarafta işin can sıkan kısmı çoğu zaman teknik değil, operasyon oluyor. Özellik güzel olabilir, hatta baya iş görebilir; ama ortada yüzlerce repo varsa, elle tıklamak insanı yoruyor. İşte GitHub’ın yeni Repository Enablement API hamlesi bu yüzden anlamlı.
Ben bunu ilk duyduğumda aklıma hemen 2019’da bir finans kuruluşunda yaptığımız DevOps dönüşümü geldi. O zamanlar statik analiz araçlarını ekip ekip yaymaya çalışıyorduk ve en büyük dert yine aynıydı: merkezî yönetim yoksa standart da olmuyor. Şimdi GitHub burada işi — ki bu tartışılır — biraz daha olgunlaştırmış gibi dürüyor. Kağıt üstünde iyi, pratikte işe birkaç ince detay var; onları da aşağıda açacağım.
Durun, bir saniye.
Bir de şu var: Bu yenilik sadece “bir ayar endpoint’i” değil. Aslında kurumsal yazılım yönetiminde küçük ama etkisi hissedilen bir kırılma. Repo seviyesinde kalite kapısını programatik açıp kapatabiliyorsunuz, hangi diller taranacak seçiyorsunuz, hangi runner kullanılacak belirliyorsunuz. Sız hiç denediniz mi? Yanı mesele sadece kod kalitesi değil; yönetişim, ölçek ve tekrar edilebilirlik.
Neden Bu API Dikkat Çekiyor?
GitHub Code Quality için gelen yeni uç noktalar net dürüyor: biri ayarı yapıyor, diğeri mevcut durumu okuyor. PATCH ile default setup’ı açıp kapatıyorsunuz, dil listesini belirliyorsunuz ve runner tipini seçiyorsunuz. GET tarafında işe mevcut durum, analiz zamanı, diller ve runner bilgisi geliyor (kendi tecrübem). Basit görünüyor. Zaten iyi tasarlanmış yönetim aracı çoğu zaman böyle olur; gösteriş yapmaz ama iş görür.
Şunu söyleyeyim, Burada beni en çok düşündüren şeylerden biri, bunun public preview olarak gelmesi ama Enterprise Server’da henüz olmaması. Yanı bulutta hızlı ilerleyen bir özellik var, fakat kurum içi sunucuda çalışan ekipler biraz bekleyecek gibi. Ben bunu özellikle büyük bankalarda çok gördüm: bulut tarafı hızlanıyor, on-prem tarafı işe güvenlik ve uyumluluk nedeniyle geriden geliyor. Hayal kırıklığı mı? Biraz evet.
Peki neden?
2024’ün Kasım ayında Logosoft tarafında yürüttüğümüz bir projede benzer bir standardizasyon ihtiyacı vardı. Farklı ekiplerin farklı araçlarla kodu taraması yüzünden raporlar birbirini tutmuyordu. Orada öğrendiğim şey şu öldü: teknoloji kadar rollout stratejisi de önemli. Eğer elinizde 80 repo varsa ve her birini elle yönetiyorsanız, sorun teknoloji değil süreçtir.
Şahsen, Bu API’nın değeri tam burada başlıyor: merkezî otomasyonla tekrar eden işleri kesiyor. Küçük startup için bu belki “güzel ekstradır”, ama enterprise seviyede doğrudan operasyonel rahatlık demek.
Peki hangi diller destekleniyor?
Vallahi, Şimdilik desteklenen dil listesi fena değil: C#, Go, Java/Kotlin, JavaScript/TypeScript, Python ve Ruby. Özellikle.NET ağırlıklı ekiplerde C# desteği hayatı çünkü bizim tarafta hâlâ ciddi bir kitle bu stack üzerinde yaşıyor.
Ha bu arada, dil desteği iyi ama sınırsız değil. Mesela bazı organizasyonlarda PHP veya Rust gibi diller de ana akım olabiliyor; onlar için bu özellik şu an tam çözüm sayılmaz (yanlış duymadınız). Yanı burada “her şeyi çözdü” demek doğru olmaz.
Nasıl Kullanılır? Mantık Basit Ama İnce Noktalar Var
Açık konuşayım, API mantığı sade olduğu için öğrenmesi kolay. Ama sade olması sizi yanıltmasın; yetkilendirme modeli, repo kapsamı ve otomasyon sırası yanlış kurulursa güzel başlayan iş çabuk karışır. Ben AZ-305 sınavına hazırlanırken hep şunu düşünürdüm: mimarı kararlar küçük ayrıntılarda belli olur. Burada da öyle.
Aşağıdaki yapı kabaca ne yaptığınızı anlatıyor:
{
"enabled": true,
"languages": ["csharp", "javascript-typescript", "python"],
"runner_type": "github-hosted",
"analysis_schedule": "daily"
}Açık konuşayım, Bu örnekte üç dili aynı anda açıyorsunuz ve hosted runner kullanıyorsunuz. Küçük ekipler için bu gayet pratik; ekstra bakım yükü çıkarmıyor. Büyük kurumlarda işe ben genelde önce policy bazlı yaklaşımı öneriyorum: hangi repolar pilot olacak, kim onay verecek, sonuçlar nereye düşecek… Bunlar netleşmeden toplu yayına geçmek riskli olur (kendi tecrübem)
Bence en iyi kullanım senaryosu şurada ortaya çıkıyor: repository provisioning sırasında Code Quality’nın otomatik açılması. Yanı yeni repo doğduğu anda kalite politikası da yanında geliyor. Elle işlem azalıyor mu? Evet. Tutarlılık artıyor mu? Kesinlikle.
| Senaryo | Küçük Ekip | Kurumsal Yapı |
|---|---|---|
| Açma yöntemi | Elle deneme + az sayıda repo | API ile otomasyon + policy tabanlı rollout |
| Dil kapsamı | Ekipte kullanılan ana diller | Sözleşmeli standart dil seti |
| Runner tercihi | Mümkünse hosted runner | Gerekiyorsa self-hosted / kontrollü altyapı |
| Kritik nokta | Sadelik | Uyum ve denetlenebilirlik |
Bence Asıl Mesaj Otomasyon Tarafında Saklı
İnanın, Neyse uzatmayalım; bu haberin özü kalite aracından çok otomasyon kabiliyetiyle ilgili. GitHub bize artık “tek tek tıklama” yerine “repo yaşam döngüsüne kalite ekleme” fikrini veriyor. Bu yaklaşım bana Azure tarafındaki policy-first düşüncesini hatırlatıyor — yanı sistemi sonradan yamamak yerine baştan kurallarla şekillendirmek.
Bunu Türkiye’deki şirketler açısından değerlendirirsek tablo biraz daha ilginçleşiyor. Bizde birçok kurum hâlâ proje bazlı düşünüyor; oysa kalite araçları proje bitince kapanan şeyler değil, sürekli yaşayan kontrol katmanlarıdır. Eğer organizasyonda ekip değişimi sık yaşanıyorsa ya da dış kaynak kullanımı fazlaysa bu API baya değerli olur. Standardı kişilere bırakmazsınız.
Kendi sahadaki gözlemim şu: orta ölçekli şirketler genelde “önce hızlı gidelim” diyor. Sonra teknik borç faturası patlıyor.
2025’in Mart ayında Ankara’daki bir üretim firmasına yaptığımız değerlendirmede tam bunu gördük; iki ayrı takım aynı repo ailesinde farklı kalite kuralları kullanıyordu.
Sonuç? Raporlar tutmuyor, tartışmalar uzuyordu.
İşte böyle durumlarda merkezî enablement yaklaşımı çok iş görüyor.
Şöyle söyleyeyim, E tabi eksik tarafları da var.
Public preview olması nedeniyle davranışlar değişebilir.
Enterprise Server’da olmaması bazı kurumlar için direkt engel.
Bir de herkesin runner modeline göre aynı deneyimi alacağını varsaymak doğru olmaz; bazı yapılarda hosted runner yeterli gelirken bazı yapılarda veri yerelliği nedeniyle self-hosted şart olabilir.
Yanı güzel özellik ama henüz ham… biraz daha pişmesi lazım.
Dikkat edilmesi gerekenler
- Kapsamı dar tutun: İlk etapta tüm repolar yerine pilot gruplarla başlayın.
- Dil listesini temizleyin: Gerçekten kullanılan dilleri seçin; gereksiz tarama maliyet yaratır. (bu kritik)
- Runner kararını netleştirin: Hosted mı self-hosted mı baştan belirleyin.
- Anahtar yönetimini unutmayın: Yetkisiz enable/disable işlemleri can sıkabilir.
- Kayıt tutun: Kim ne zaman neyi açtı mutlaka loglansın.
Repo bazlı kalite otomasyonu küçük görünür ama büyük organizasyonlarda asıl farkı yaratan şey çoğu zaman budur: tekrar eden işleri azaltır, standardı korur ve denetimi kolaylaştırır.
Tam Burada Pratik Bir Uygulama Planı Var
Eğer bunu denemek istiyorsanız ilk iş şu üç adımı atın:
1) Bir pilot repo grubu seçin,
2) Kod sahibi ekiplerle dili ve runner’ı netleştirin,
3) PATCH çağrısını önce staging benzeri bir ortamda test edin.
Bu kadar basit görünüyor ama inanın birçok proje burada takılıyor çünkü kimse başlangıçta sahipliği tanımlamıyor.
Aslında — dur bir saniye — teknikten çok organizasyon konuşuyoruz yine! (kendi tecrübem)
Peki, kendi deneyimimden konuşuyorum, Zamanlama konusunda da şunu söyleyeyim:
Yeni oluşturulan repolara otomatik uygulanacak şekilde pipeline’a bağlamak en temiz yol olabilir.
Mesela Actions" data-glossary-term="GitHub Actions">GitHub Actions veya başka bir provisioning akışı içinde bu endpoint’i çağırırsınız;
repo oluşur,
kalite açılır,
diller set edilir…
bitti gitti.
Ama burada hata payını küçümsemeyin;
ilk denememde yanlış scope yüzünden “404 not found” almıştım.
Sorun endpoint’te değilmiş,
repo owner bilgisini yanlış map etmişiz.
Klasik ama öğretici bir hata!
Şunu söyleyeyim, Bütçe tarafını da es geçmeyelim.
Bulut tabanlı taramalar küçük TL bazında bile toplandığında hissedilir hâle gelebiliyor;
özellikle aktif branch sayısı yüksekse analiz maliyeti sessizce büyür.
Bütçe kısıtlıysa önce en kritik repolarla başlayın,
sonra genişletin.
Herkese her şeyi aynı gün açmak kulağa hoş gelir ama FinOps açısından pek parlak değildir…
Durun, bir saniye.
Sıkça Sorulan Sorular
GitHub Code Quality Repository Enablement API ne işe yarıyor?
Aslında oldukça kullanışlı bir şey: repo bazında Code Quality özelliğini programatik olarak açıp kapatabiliyorsunuz. Yanı dil seçimi ve runner tipi gibi ayarları da merkezden yönetmek mümkün oluyor.
Bütün repolarda aynı anda kullanabilir mıyım?
Evet, otomasyonla yayabilirsiniz teknik olarak. Ama bence önce bir pilot grup deneyin (ciddiyim). Hani özellikle kurumsal ortamlarda direkt toplu geçiş yerine kontrollü bir rollout çok daha sağlıklı oluyor, tecrübeme göre.
Enterprise Server’da çalışıyor mu?
Hayır. Şu an sadece github.com üzerinde public preview olarak sunuluyor. Enterprise Server desteği yok.
Küçük ekipler için mantıklı mı?
Evet, özellikle manuel işleri azaltmak isteyen küçük ekiplere faydalı oluyor. Açıkçası zaten birkaç reposu olan ekiplere ilk bakışta biraz lüks gibi gelebilir; ama asıl değer ölçek büyüyünce ortaya çıkıyor.
Kaynaklar ve İleri Okuma
GitHub Code Quality Resmî Dokümantasyonu
GitHub REST API Dokümantasyonu (kendi tecrübem)
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.
0 comments