GitHub Code Quality artık ücretli: Kurumlar neyi hesap etmeli?
İşin aslı şu ki, yazılım kalitesini “bir kontrol daha” diye gören ekipler genelde faturayı geç fark ediyor. GitHub Code Quality’nın genel kullanıma açılması da tam burada ayrı bir kırılma yaratıyor — bence çok yerinde bir karar —. Çünkü mesele sadece yeni bir özellik değil; kalite kapıları, kod kapsamı. AI destekli incelemeler tek bir çatı altında toplanıyor.
Eh, Ben bu tarz değişikliklere hep iki taraftan bakıyorum: teknik taraf ve bütçe tarafı. Teknik tarafta güzel olan şey belli; maintainability, reliability ve coverage metrikleri daha görünür oluyor. Bütçe tarafında işe hikâye biraz sertleşiyor… özellikle de aktif commit eden sayısı yüksek olan kurumlarda.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Bu duyuruda gerçekten ne değişiyor?
İlginç olan şu ki, 20 Temmuz 2026 itibarıyla GitHub Code Quality, public preview’dan çıkıp satılabilir bir ürüne dönüşüyor. Yanı artık “bir deneyelim bakalım” modundan çıkıyoruz; lisans, kullanım ve etkinleştirme kararları devreye giriyor. Fiyatlama da net: enabled repository’lerde aktif commit eden başına aylık 10 dolar temel ücret var.
Yanı, Burada hayatı nokta şu: bu sadece etiket değişimi değil. Ürünün kapsamı genişliyor. Organization-wide deployment geliyor, organization seviyesinde quality dashboard geliyor, ruleset ile code coverage enforcement geliyor. Kulağa temiz geliyor ama pratikte bu tip merkezî kalite politikaları ekiplerin alışkanlıklarını baya sarsabiliyor.
Kısa bir not düşeyim buraya.
Deterministic analiz tarafında CodeQL çalışmaları GitHub Actions minutes tüketecek — itiraf edeyim, beklentimin üstündeydi —. AI destekli kısımda işe Copilot code review, AI-assisted detection ve Autofix gibi iş yükleri usage-based modele bağlanıyor. Yanı tek bir “lisans aldım bitti” mantığı yok; kullanım şeklinize göre maliyet katmanı oluşuyor (kendi tecrübem)
Kim için iyi haber?
Büyük organizasyonlar için açık konuşayım, baya iş görüyor. Çünkü kaliteyi repo bazında bıraktığınızda kimse bütün resmî göremiyor. Merkezî dashboard ile hangi ekipte coverage düştü, hangi repoda reliability sorunu büyüyor, bunları topluca görmek kolaylaşıyor (buna dikkat edin)
Küçük ekiplerde işe durum biraz farklı. Eğer zaten sıkı code review yapıyorsanız ve basit lint/test akışınız oturduysa, bu ürün ilk gün şart olmayabilir. Hani her şeyi aynı anda almak zorunda değilsiniz ya… önce ihtiyacı ölçmek lazım. Daha fazla bilgi için .NET Day Agentic Modernization: Eski Uygulamalara Yeni Hayat yazımıza bakabilirsiniz.
Maliyet hesabını duyguyla değil veriyle yapmak lazım
Açık konuşayım: fiyatlandırma kağıt üstünde sade görünüyor ama kurum ölçeğinde hızlıca büyüyebilir. Örneğin 40 aktif committer varsa temel lisans kabaca aylık 400 dolar eder; bunun üstüne AI kullanımını ve Actions dakika tüketimini eklediğinizde tablo değişir. İlginç, değil mi? TL bazında düşündüğünüzde kur oynaklığı da cabası. Daha fazla bilgi için Claude Fable 5 Microsoft Foundry’de: Otonom Ajan Devri Başlıyor yazımıza bakabilirsiniz.
Vallahi, Burada ben genelde FinOps bakışı öneriyorum. Kalite aracı diye başlayan şey zamanla platform harcamasına dönüşebiliyor çünkü pull request hacmi arttıkça AI inceleme çağrıları da artıyor (bu beni çok şaşırttı). Neden önemli bu? En çok da enterprise yapılarda her repo için aynı paketi açmak yerine pilot uygulama yapmak çok daha akıllıca olur.
Durun, bir saniye.
| Bileşen | Neye yarıyor? | Maliyet etkisi |
|---|---|---|
| Aktif committer lisansı | Temel erişim ve quality gate’ler | Sabit aylık ücret |
| AI-powered work | Copilot review, autofix, AI detection | Kullanım bazlı artar |
| Detereministic analysis | CodeQL tabanlı taramalar | GitHub Actions minutes tüketir |
Neyse uzatmayalım; bütçeyi planlarken üç soru sorun: Kaç kişi gerçekten commit ediyor? Kaç repo korunacak? AI incelemeyi her PR’da mı çalıştıracaksınız yoksa sadece hayatı repolarda mı? Bu üç cevap çoğu zaman faturanın kaderini belirliyor.
Küçük startup vs enterprise yaklaşımı
Küçük startup için önerim net: önce birkaç kilit repository seçin, quality gate’i dar tutun ve Coverage enforcement’ı aşırı sert başlamayın. Çünkü erken aşamada hız önemli; her merge’e ağır kapılar koyarsanız ekip işi yavaşlatır. Copilot CLI’da Akıllı Subagent Delegasyonu: Az Devretmek Daha İyi yazımızda bu konuya da değinmiştik.
Enterprise tarafta işe tersine düşünmek gerekiyor. Orada standardizasyon değerli olduğu için organization-level dashboard çok işe yarar. Bir de governance açısından ruleset ile kod kalitesi eşiklerini güvenlik kurallarıyla birlikte yönetmek ciddi rahatlık sağlar (tabi doğru kurgulanırsa). PowerToys 0.100: Shortcut Guide ve Command Palette Yenilendi yazımızda bu konuya da değinmiştik.
Sahada en çok nerede fayda verir?
İşin garibi, Bence en güçlü tarafı görünmez borcu görünür yapması. Maintainability score düşükse bunu sadece senior gözle görmek yerine sistematik olarak yakalıyorsunuz. Reliability sorunları da aynı şekilde… testten geçen ama gerçek hayatta can sıkan parçalar daha erken ortaya çıkabiliyor.
E tabi işin güzel kısmı kadar eksik kısmı da var: Her metrik gerçeği anlatmaz! Mesela coverage yüzde olarak yüksek olabilir ama anlamlı assertion yoksa o testler sizi pek korumaz (en azından benim deneyimim böyle). O yüzden ben quality score’u tek başına hüküm verici değil, yön gösterici kabul ediyorum. Bu konuyla ilgili Copilot Autofix Azure DevOps’ta: Alert Yığını Bitiyor mu? yazımıza da göz atmanızı tavsiye ederim.
Kalite skoru iyidir ama amaç değildir; asıl amaç üretimde sürprizi azaltmak.
Sık yapılan hata ne?
Sahada şunu sık görüyorum: ekipler quality gate’i açıyor ama exception politikasını konuşmuyor. Sonra ilk hafta onlarca PR bloklanıyor ve herkes panikliyor… halbuki çözüm basit; eşikleri kademeli yükseltmek gerekiyor.
Bir başka yaygın hata da sadece yeni repolara odaklanmak oluyor. Eski depoların borcu genelde daha büyük olduğu için asıl kazanç oradan gelir ama migrasyon sabrı ister yanı hemen sonuç beklememek lazım.
- Önce pilot repo seçin.
- Kritik olmayan branch’lerde soft warning ile başlayın.
- Coverage hedefini bir anda tavana vurmayın.
- AI review kullanımını hayatı alanlara sınırlayın.Aksiyonlardan sonra ölçün; körlemesine genişletmeyin.
Bunu Türkiye’deki şirketler nasıl okumalı?Bence Türkiye’de konuya yaklaşım biraz farklı olacak çünkü döviz bazlı SaaS maliyeti anında hissediliyor. ABD merkezinde “10 dolar/committer” kulağa küçük gelebilir ama kur çevrilince orta ölçekli şirketlerde bile dikkat çekiyor. Hele yüzlerce geliştiriciniz varsa tablo hızla kabarıyor….
Bir şey dikkatimi çekti: Kurum müşterilerinde gördüğüm kadarıyla bizde en sağlıklı model şu oluyor: önce güvenlik ve kaliteyi aynı masaya oturtmak, sonra maliyet takibini NetApp misali sayısallaştırmak değil tabiî — FinOps disiplinine bağlamak. Böylece hem teknik lider hem finans ekibi aynı rapora bakabiliyor.Tam burada pratik önerim şu:Kullandığınız repo listesini çıkarın.Aktif commit edenleri son 30 güne göre ölçün.Pilot ortamda Actions minute tüketimini izleyin.Copilot destekli özellikleri varsayılan açık bırakmayın.Tüm org’a yaymadan önce maliyet senaryosu oluşturun.Nereden başlanmalı?;
Lafı gevelemeden söyleyeyim: önce politika yazın, sonra araç alın. Kalite kapısı nasıl işleyecek, kim istisna verecek, hangi eşikte merge duracak — bunlar önceden net olmalı (inanın bana). Aksi hâlde teknoloji var ama operasyon yok olur. İşte o zaman ürünün kendisi değil süreci tartışır durursunuz.Eğer GitHub Enterprise Cloud veya Team planındaysanız uygunluk açısından avantajınız var. Ama Enterprise Server kullanan kurumlar için kötü haber şu ki bu özellik orada yok: Bu yüzden hibrit çalışan yapılarda mimarı kararlar ayrıca değerlendirmek lazım; bazı takımlar cloud’da kalite yönetirken bazıları on-prem kalabilir.# Basit başlangıç kontrol listesi
1) Enable edilecek repository'leri seç
2) Aktif committer sayısını doğrula
3) Coverage threshold belirle
4) Actions minute bütçesini izle
5) Pilot sonrası rollout kararı ver
Sıkça Sorulan Sorular
GitHub Code Quality ücretsiz mi olacak?
Hayır. Duyuruya göre ürün genel kullanıma çıktığında ücretli olacak. Temel lisans aktif committer başına aylık 10 dolar olarak fiyatlanıyor, buna ek olarak AI özelliklerinde de kullanım bazlı ücret var. Hani bir de deterministic analiz GitHub Actions minutes tüketiyor. Yanı toplam maliyet, kullanımınıza göre değişiyor.
Daha önce public preview kullananlar ne yapmalı?
Eğer devam etmek istemiyorsanız July 20’den önce repository seviyesinde disable etmeniz gerekiyor. Organizasyon ayarlarından toplu kapatma da mümkün olacak deniyor. Açıkçası bence en güvenlisi, erişimleri şimdi gözden geçirmek; son ana bırakmamak.
Enterprise Server destekleniyor mu?
Vallahi, Hayır, bu sürüm yalnızca GitHub Enterprise Cloud ve GitHub Team planlarında kullanılabiliyor (evet, doğru duydunuz). Enterprise Server tarafında destek yok. Mesela self-hosted ağırlıklı kurumların buna göre alternatif plan yapması gerekebilir.
Maliyet nasıl düşürülür?
Pilot uygulamayla başlamak iyi bir fikir. AI desteklerini sınırlayın ve deterministic scan’leri kritik repolara odaklayın. Ayrıca gereksiz bot commit’lerini azaltmak da aktif committer sayısını etkileyebilir. Tecrübeme göre, küçük optimizasyonlar toplamda ciddi fark yaratıyor.
Kaynaklar ve İleri Okuma
GitHub Docs — Code Quality Hakkında
İnanın, GitHub Actions Resmî 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.
Yorum gönder