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. Yani 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.
Yani, 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. Yani 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
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).
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.
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. Yani 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.
3 comments