Bir yazılım ekibi büyüdükçe "kodu birleştirmeden önce ne kontrol edelim?" sorusu er ya da geç gündeme gelir. Bu sorunun cevabı genellikle önce insan gözüyle yapılan kod incelemesiyle başlar, sonra otomasyona doğru evrilir. İşte bu evrimin merkezinde kod kalite kapısı (quality gate) kavramı yer alır. Bu makalede kalite kapılarının ne olduğunu, CI/CD hattında nereye oturduğunu ve pratikte nasıl kurgulanabileceğini genel bir çerçevede ele alıyoruz.
Bir bakışta
- Kalite kapısı, build'in eşik değerleri karşılayıp karşılamadığını otomatik olarak denetleyen bir mekanizmadır.
- Kapsama oranı, kod tekrarı, karmaşıklık ve güvenlik açığı gibi metrikler kapı kararlarının temelini oluşturur.
- Eşik değerleri mevcut kod tabanına göre kademeli olarak belirlenmeli ve zamanla sıkılaştırılmalıdır.
Kod Kalite Kapısı (Quality Gate) Nedir?
Kod kalite kapısı, bir build'in "başarılı" mı yoksa "başarısız" mı sayılacağına karar veren, önceden belirlenmiş eşik değerleri bütünüdür. Örneğin "test kapsama oranı en az %70 olmalı" veya "kritik seviye güvenlik açığı sıfır olmalı" gibi kurallar bu bütünü oluşturur. Bir build bu eşiklerden herhangi birini karşılamıyorsa kapı kapanır, kod bir sonraki aşamaya (örneğin dağıtıma) geçemez.
Burada önemli bir ayrım var: kalite kapısı bir insan onayı değildir, otomatik ve objektif işleyen bir denetim noktasıdır. Bir geliştiricinin "bence bu kod yeterince iyi" demesiyle kalite kapısının "bu kod tanımlı eşikleri karşılıyor" demesi farklı şeylerdir. İkincisi öznel yorumdan bağımsız, tekrarlanabilir bir karardır.
Neden sadece "testler geçti mi" sorusu yeterli değildir? Çünkü testlerin geçmesi kodun çalıştığını gösterir, ama kodun bakımı kolay mı, güvenli mi, gelecekte sorun çıkarma potansiyeli var mı gibi soruları cevaplamaz. Kalite çok boyutlu bir kavramdır; fonksiyonel doğruluk bu boyutlardan sadece biridir. Kalite kapısı, bu farklı boyutları tek bir karar noktasında birleştirmeye çalışır.
CI/CD Hattında Kalite Kapıları Nerede Devreye Girer
Tipik bir CI/CD pipeline'ı genellikle şu sırayla ilerler: kaynak kodun derlenmesi (build), birim testlerin çalıştırılması, statik analiz, güvenlik taraması ve son olarak dağıtım öncesi kontroller. Kalite kapısı, teoride bu aşamaların herhangi birinin sonunda devreye girebilir.
Örneğin test aşamasının sonunda kod kapsama oranına dayalı bir kapı tanımlanabilir. Statik analiz aşamasının sonunda kod kokusu (code smell) sayısına veya karmaşıklık skoruna dayalı bir başka kapı çalışabilir. Güvenlik taraması sonrasında ise açık sayısına ve önem derecesine dayalı bir kapı işletilebilir. Yani tek bir "büyük kapı" olmak zorunda değildir; pipeline boyunca birden fazla kontrol noktası tanımlanabilir.
Burada dikkat edilmesi gereken bir başka nokta, kapının pipeline'ı fiilen durdurma yetkisine sahip olup olmadığıdır. Bazı ekipler kalite kapısını "blocking" (engelleyici) olarak kurar; kapı geçilmezse merge veya deploy işlemi fiziksel olarak gerçekleşmez. Bazı ekipler ise başlangıçta sadece uyarı (warning) modunda çalıştırır; kapı başarısız olsa bile pipeline devam eder, ancak ekip bilgilendirilir. Yeni bir kalite kapısı sürecine geçerken uyarı modundan başlamak, ekibin alışması için gerçekçi bir ara adım olabilir.
Kalite Kapılarının Dayandığı Yaygın Metrikler
Kalite kapıları genellikle birkaç metrik kategorisi üzerine kurulur:
Kod kapsama oranı (test coverage): Kodun ne kadarının testlerle çalıştırıldığını gösterir. Ancak bu oranın yüksek olması testlerin anlamlı olduğu anlamına gelmez; sadece kodun çalıştırıldığını gösterir, doğru sonucu doğruladığını garanti etmez. Bu yüzden kapsama oranı tek başına yeterli bir kalite göstergesi değildir, ama faydalı bir sinyal sağlar.
Kod tekrarı (duplication): Aynı veya çok benzer kod bloklarının proje içinde birden fazla yerde bulunması. Tekrar oranı yükseldikçe bir hatayı düzeltmek için birden fazla yeri güncellemek gerekebilir, bu da bakım maliyetini artırır.
Döngüsel karmaşıklık (cyclomatic complexity): Bir fonksiyon veya metodun içindeki bağımsız yürütme yollarının sayısını ölçer. Yüksek karmaşıklık genellikle okunması ve test edilmesi daha zor kod anlamına gelir.
Güvenlik açığı sayısı: Güvenlik tarama araçlarının tespit ettiği zafiyetlerin sayısı. Burada tek bir toplam sayı yerine kritik, yüksek, orta ve düşük seviyelere göre sınıflandırma yapmak daha anlamlıdır; çünkü bir kritik açık, on düşük seviyeli bulgudan daha öncelikli olabilir.
Kod kokuları (code smells): Doğrudan hataya yol açmayan ama uzun vadede bakım sorunlarına işaret eden yapısal örüntüler (örneğin aşırı uzun fonksiyonlar, gereksiz karmaşık koşul zincirleri). Statik analiz araçları bu tür örüntüleri kural setleri üzerinden tespit edip raporlar.
Statik Analiz ve Güvenlik Tarama Araçlarının Rolü
Kalite kapısı kendisi bir ölçüm aracı değildir; kararını verecek ham veriyi statik analiz ve güvenlik tarama araçlarından alır. Yani kalite kapısı bir "hakem", bu araçlar ise sahaya veri toplayan "gözlemciler" gibi düşünülebilir.
Statik analiz araçları kaynak kodu çalıştırmadan tarar; karmaşıklık, tekrar, kod kokusu gibi metrikleri sayısal değerlere dönüştürür. Bu sayısal çıktılar kalite kapısının eşiklerle karşılaştırdığı girdilerdir. Güvenlik tarama araçları da benzer şekilde bilinen zafiyet kalıplarını veya bağımlılıklardaki güvenlik açıklarını tespit eder ve bunları önem derecesine göre etiketler. Kalite kapısı tanımında "kritik seviye açık varsa build başarısız olsun, orta seviye açıklar sadece raporlansın" gibi kurallar bu etiketleme sayesinde mümkün olur.
Burada seçilen aracın niteliği, kapının güvenilirliğini doğrudan etkiler. Yanlış pozitif üreten veya belirli bir dil/çerçeve için zayıf destek sunan bir araç, kalite kapısının anlamsız yere kod bloklamasına veya gerçek sorunları gözden kaçırmasına yol açabilir. Bu yüzden araç seçimi, kapı tanımından önce gelen ama kapı tanımını doğrudan şekillendiren bir karardır.
Eşik Değerleri Nasıl Belirlenmeli
Eşik değerlerin belirlenmesinde en yaygın hata, endüstri ortalamalarını veya başka bir projenin eşiklerini doğrudan kopyalamaktır. Oysa her kod tabanının geçmişi, teknoloji yığını ve olgunluk seviyesi farklıdır. Doğru yaklaşım, mevcut kod tabanının gerçekçi durumunu ölçüp bir başlangıç noktası (baseline) çıkarmaktır. Örneğin mevcut kapsama oranı %55 ise, eşiği doğrudan %90'a çekmek yerine önce %60 gibi ulaşılabilir bir hedefle başlamak daha sürdürülebilirdir.
Aşırı katı eşikler geliştirme sürecini kilitleyebilir: ekip her build'de kapıyı geçemediği için ya iş yapamaz hale gelir ya da kapıyı atlamanın yollarını arar (ki bu, kapının amacını tamamen boşa çıkarır). Aşırı gevşek eşikler ise kapıyı anlamsızlaştırır; her şey geçtiği için kimse kapıya dikkat etmez.
Sürdürülebilir bir yaklaşım, eşikleri kademeli olarak sıkılaştırmaktır. Ekip belirli bir eşiğe birkaç sprint boyunca rahatça uyduğunda, eşik biraz daha yükseltilir. Bu, hem ekibin kapıyı bir engel değil bir rehber olarak görmesini sağlar hem de kalite standardının zamanla organik olarak yükselmesine izin verir.
Yeni Kod ile Eski Kod İçin Farklı Stratejiler
Var olan bir kod tabanına yeni bir kalite kapısı uygulamaya karar verildiğinde, sık yapılan bir hata tüm kod tabanına aynı sıkı eşikleri aynı anda uygulamaktır. Yıllar içinde biriken teknik borcu bir gecede temizlemek beklentisi gerçekçi değildir ve genellikle ekipte direnç yaratır.
Bunun yerine yaygın kabul gören yaklaşım, "yeni kod üzerinde kalite kapısı" mantığıdır: kalite kapısı, sadece yeni eklenen veya değiştirilen kod parçalarına uygulanır. Eski, dokunulmamış kod şimdilik olduğu gibi kalır, ama bir geliştirici o dosyaya dokunduğu anda değiştirdiği kısım kalite standardına tabi olur.
Bu ayrım pratikte iki fayda sağlar. Birincisi, ekip "önce tüm eski hataları düzelt" gibi imkânsız bir görevle karşı karşıya kalmaz. İkincisi, kod tabanı zamanla organik olarak iyileşir; çünkü aktif olarak üzerinde çalışılan bölümler yavaş yavaş yeni standarda uyum sağlar, terk edilmiş kod ise en azından daha fazla kötüleşmez. Bu yaklaşım aynı zamanda ekibin kalite kapısını "cezalandırıcı" değil "adil" bir mekanizma olarak kabullenmesini kolaylaştırır.
Kalite Kapısı Başarısız Olduğunda İzlenecek Adımlar
Kapı kapandığında sürecin ne olacağı önceden tanımlanmalıdır, yoksa her başarısızlık ekipte kafa karışıklığına yol açar. İlk adım genellikle bir bildirimdir: pipeline çıktısında görünür bir hata mesajı, ekip iletişim kanalına otomatik bildirim veya değişikliği yapan geliştiriciye doğrudan atama gibi mekanizmalar kullanılabilir.
Bildirimden sonra düzeltme sürecinin önceliklendirilmesi gerekir. Örneğin kritik bir güvenlik açığı tespit edildiyse bu, diğer işlerin önüne geçmelidir; ama küçük bir kod kokusu uyarısı aynı aciliyeti taşımayabilir.
Bazı durumlarda kapının geçici olarak aşılması (istisna/override) gerekebilir — örneğin acil bir üretim hatası düzeltmesinin bekleyemeyeceği durumlarda. Ancak istisna mekanizması keyfi kullanılmamalıdır; her istisna kim tarafından, hangi gerekçeyle onaylandığı kayıt altına alınmalıdır. Bu şeffaflık olmadan istisnalar zamanla kuralın kendisinden daha sık kullanılan bir kaçış yoluna dönüşebilir ve kalite kapısının tüm anlamını yitirmesine yol açabilir.
Zamanla Gözden Geçirme ve Ekip Olgunluğuna Göre Güncelleme
Kalite kapısı bir kez tanımlanıp unutulacak statik bir kural seti değildir; ekiple birlikte yaşayan bir yapılandırmadır. Ekibin deneyimi ve kod tabanının olgunluğu arttıkça eşiklerin de gözden geçirilmesi gerekir.
Bu gözden geçirme işini rastgele değil, düzenli aralıklarla yapmak daha sağlıklıdır. Örneğin retrospektif toplantılarında veya periyodik değerlendirmelerde "bu eşik hâlâ anlamlı mı, çok mu kolay geçiliyor, yoksa sürekli engelleyici mi oluyor" sorusu tartışılabilir. Bu sayede kalite kapısı, ekibin büyümesiyle birlikte gelişen bir araca dönüşür, donmuş bir bürokratik engel olmaktan çıkar.
Denge Kurmak: Ne Çok Sıkı Ne Çok Gevşek
Kalite kapılarının en büyük riski iki uçta yaşanır. Aşırı sıkı kapılar geliştirici deneyimini yıpratabilir: her küçük değişiklik uzun bir onay sürecine dönüşür, pipeline yavaşlar, geliştiriciler kapıyı bir engel olarak görmeye başlar ve motivasyon düşer. Diğer uçta, hiç kalite kapısı olmaması ise teknik borcun sessizce birikmesine, güvenlik açıklarının fark edilmeden üretime taşınmasına ve kod tabanının zamanla yönetilemez hale gelmesine yol açar.
Takım liderleri için asıl zorlu olan, bu iki uç arasında sürdürülebilir bir orta yol bulmaktır. Bu denge, tek seferlik bir kararla değil; baseline'dan başlayıp kademeli sıkılaştırma, yeni kod ile eski kod ayrımı, şeffaf istisna yönetimi ve düzenli gözden geçirme gibi pratiklerin birlikte uygulanmasıyla zamanla inşa edilir. Kalite kapısı ne kadar iyi kurgulanırsa, ekip için bir denetim korkusu değil, güven verici bir güvenlik ağı haline gelir.
