GitLab; Git repository, merge request, issue tracking, CI/CD, container registry, package registry ve uygulama güvenliği özelliklerini tek platformda birleştiren DevSecOps ürünüdür. GitLab’ın asıl vaadi “tek ekranda çok özellik” değil; kod, pipeline, artifact, güvenlik bulgusu ve release süreçlerinin aynı proje ve yetki modeli etrafında yönetilmesidir.
GitLab’ı değerlendiren ekiplerin önünde genellikle üç karar vardır: hangi lisans katmanı gerekiyor, kurulum SaaS’ta mı kendi altyapınızda mı olacak ve işletme sorumluluğunu kim taşıyacak. Bu sayfa bu üç soruya odaklanır.
GitLab ne zaman mantıklı olur?
GitLab şu durumlarda güçlü bir adaydır:
- Kod, CI/CD, registry ve güvenlik taramalarını tek ürün içinde yönetmek istiyorsanız.
- Self-managed kurulumla veri, ağ ve erişim kontrollerini kurum içinde tutmanız gerekiyorsa.
- Merge request, pipeline, ortam ve deployment kayıtlarının aynı projede görünmesi karar süreçlerini kolaylaştırıyorsa.
- GitLab Runner ve Container Registry gibi bileşenleri merkezi bir DevOps standardı haline getirmek istiyorsanız.
- Güvenlik bulgularını pipeline ve merge request akışına bağlamak istiyorsanız.
Bu avantajın karşılığı, GitLab’ın kendi operasyon modelini ciddiye almaktır. GitLab sunucusu, runner’lar, registry storage, yedekler, yükseltmeler ve kullanıcı yetkileri birlikte tasarlanmalıdır.
SaaS ve self-managed ayrımı
GitLab.com, hızlı başlamak ve operasyon yükünü azaltmak isteyen ekipler için uygundur. Self-managed GitLab ise kendi altyapınızda çalışır; regülasyon, veri ikametgâhı, kapalı ağ veya özel entegrasyon gerektiren kurumlarda tercih edilebilir.
Self-managed seçildiğinde sorumluluklar:
- Sürüm yükseltme ve bakım pencereleri
- Yedekleme ve geri dönüş testi
- PostgreSQL, Redis, Gitaly ve object storage kapasitesi
- Container Registry storage ve temizlik politikaları
- Runner ölçekleme ve izolasyonu
- LDAP/SAML/SSO entegrasyonu ve yetki modeli
- Log, metrik ve denetim izleri
SaaS seçildiğinde bu altyapı yükünün önemli kısmı azalır; fakat veri konumu, ağ erişimi, runner erişimi ve plan özellikleri yine ayrıca değerlendirilir.
Lisans ödemeden çalışan kurulum
Bizim işimiz GitLab’ı ücretli plana geçmeden çalıştırmak. Kendi sunucunuzdaki ücretsiz sürüm; Git deposu, CI/CD, container registry ve paket deposu için lisans istemez. Eksik kalan kurumsal özelliklerin yerine açık kaynak bileşenler koyuyoruz:
| İhtiyaç | Ücretsiz sürümde çözümü |
|---|---|
| Pipeline kapasitesi | Kendi runner’larınız; dakika ücreti yok |
| Statik kod analizi | GitLab’ın SAST job’ı |
| Gizli anahtar taraması | GitLab’ın Secret Detection job’ı |
| Container imajı deposu | GitLab Container Registry veya Harbor |
| Kimlik yönetimi | Keycloak veya LDAP üzerinden tek oturum |
| İzleme ve loglama | Prometheus, Grafana, Loki |
| Yedekleme | Kendi yedek ve geri yükleme akışınız |
Bu modelde maliyet lisanstan işletmeye kayar: sunucu kapasitesi, depolama, yedekleme ve bakım. Deneyimimizde bütçeyi şaşırtan kalem lisans değil, registry ve artifact depolamasının sessizce büyümesi ile pipeline’ların tükettiği işlem süresidir. İkisi baştan sınırlandırıldığında ücretsiz sürüm çoğu ekip için uzun süre yeterli olur.
Ücretli plan gerçekten gerekli hâle geliyorsa bunu da açıkça söylüyoruz: kurumsal denetim raporlaması, merkezî zafiyet yönetimi ve sözleşmeli destek zorunluluğu varsa lisans konuşulur.
GitHub ile pratik fark
GitHub, açık kaynak ekosistemi ve geliştirici alışkanlığı açısından güçlüdür. GitLab ise yerleşik CI/CD, runner, registry ve güvenlik yüzeyini daha bütünleşik sunar. Bu fark satın alma kararına şöyle yansır:
- Ekip GitHub’a alışkın ve Actions ihtiyacı karşılıyorsa GitHub’da kalmak en düşük maliyetli seçenektir; araç değiştirmenin görünmeyen bedeli alışkanlıklardır.
- CI/CD, registry ve güvenlik raporlarını tek üründe toplamak istiyorsanız GitLab daha az entegrasyon işi çıkarır.
- Kendi sunucunuzda barındırma ihtiyacı varsa iki ürün de bunu destekler; fark özelliklerde değil, işletme yükünün ağırlığındadır.
- Güvenlik tarafında “var/yok” tablosu yanıltır. Asıl soru, taramanın hangi planda geldiği değil, bulguları kimin değerlendireceğidir.
GitLab bileşenleri birlikte tasarlanmalı
GitLab kurulumu yalnızca web arayüzünden ibaret değildir:
- GitLab Runner: Job’ların nerede ve hangi yetkiyle çalışacağını belirler.
- GitLab Registry: Container image’ların proje bazlı saklandığı yerdir.
- GitLab SAST: Kaynak kodu analiz ederek güvenlik bulgularını pipeline’a taşır.
- GitLab DAST: Çalışan uygulamayı test eder; resmi dokümana göre Ultimate katmanındadır.
- Object storage: Artifact, LFS, upload ve registry büyümesini yönetmek için kritik hale gelir.
Bu parçalar ayrı ayrı iyi yapılandırılsa bile, yetki ve veri akışı birlikte düşünülmezse gereksiz risk oluşur. Örneğin runner’ın production ağına erişmesi, registry’de temizleme politikası olmaması veya güvenlik bulgularının sorumlusuz kalması, platform değerini düşürür.
Resmi kaynaklar
- Plan ve lisans ayrımı için GitLab Pricing
- Ürün dokümantasyonu için GitLab Docs
- SAST kapsamı için GitLab SAST documentation
- DAST kapsamı için GitLab DAST documentation
Mono ne zaman yardımcı olur?
- GitLab vs GitHub seçim atölyesi
- SaaS / self-managed karar analizi
- GitLab Omnibus veya referans mimari kurulumu
- Runner executor ve ölçekleme tasarımı
- Registry storage ve temizlik politikaları
- SAST/DAST/Dependency Scanning kapsam değerlendirmesi
- GitHub, Jenkins veya ayrı registry’den geçiş planı
