GitLab CI/CD ile Otomatik Dağıtım: 7 Adımda Başarılı Süreç Tasarımı ve En İyi Uygulamalar (2026)

GitLab CI/CD Nedir ve Neden Kullanmalısınız?

GitLab CI/CD, GitLab platformunun içinde yer alan bir Continuous Integration (Sürekli Entegrasyon) ve Continuous Deployment (Sürekli Dağıtım) sistemidir. Geliştiriciler kodlarını GitLab deposuna gönderdiğinde, tanımlı .gitlab-ci.yml dosyası sayesinde otomatik test, derleme ve dağıtım aşamaları başlatılır. Bu sayede manuel hatalar azalır, kod kalitesi yükselir ve ürün teslim süresi %40’a kadar kısalabilir.

GitLab CI/CD’nin en büyük avantajı, tüm sürecin tek bir platformda yönetilebilmesidir. Hem kod yönetimi hem de CI/CD aynı yerde olduğu için VDS sunucu paketleri gibi altyapı kaynaklarıyla entegrasyon sorunsuz gerçekleşir. Ayrıca, GitLab’ın ücretsiz topluluk sürümü, küçük ekipler için bile kapsamlı bir CI/CD deneyimi sunar.

GitLab CI/CD’nin Temel Bileşenleri ve Çalışma Mantığı

GitLab CI/CD üç ana bileşenden oluşur: Runner, Pipeline ve Job. Runner, bir veya birden fazla sunucuda (örneğin AMD Ryzen VDS sunucular) çalışan bir ajan olup, tanımlı işleri (job) yürütür. Pipeline, bir dizi stage (aşama) ve job’dan oluşan bir akıştır; her stage bir öncekinin başarılı olmasını bekler. Job ise gerçek komutları içeren, örneğin test çalıştırma veya Docker imajı oluşturma gibi görevlerdir.

Pipeline’ı tetiklemek iki yolla mümkündür: kod push edildiğinde otomatik tetikleme ve manuel tetikleme. Otomatik tetikleme, geliştiricinin “git push” komutunu kullanmasıyla gerçekleşir; bu sayede testler anında çalışır ve hatalar erken aşamada yakalanır. Manuel tetikleme ise özellikle prod ortamına geçişte kontrol sağlamak için tercih edilir.

GitLab Runner Kurulumu ve Konfigürasyonu

GitLab Runner, CI/CD işlemlerinin gerçek zamanlı olarak çalıştığı bir bileşen olduğundan, doğru kurulum ve konfigürasyon kritik öneme sahiptir. Öncelikle, runner’ı kuracağınız sunucunun minimum gereksinimlerini kontrol edin; örneğin 2 CPU, 4 GB RAM ve SSD depolama önerilir. Bu koşulları karşılayan bir Intel i9 VDS sunucu seçimi, paralel job çalıştırma kapasitenizi artırır.

Kurulum adımları şu şekildedir:

1. Runner paketini resmi GitLab reposundan indirin: curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
2. Deb paketini kurun: sudo apt-get install gitlab-runner
3. Runner’ı register edin: sudo gitlab-runner register komutu ile GitLab URL, token, description ve executor (docker, shell, kubernetes vb.) bilgilerini girin.
4. Docker executor seçtiyseniz, Docker Engine kurulu olduğundan emin olun ve sudo usermod -aG docker gitlab-runner ile gerekli izinleri verin.
5. Runner servisini başlatın ve otomatik başlatma ayarını yapın: sudo systemctl enable --now gitlab-runner

Bu adımları tamamladıktan sonra gitlab-runner list komutuyla runner’ın aktif olduğunu doğrulayabilirsiniz.

.gitlab-ci.yml Dosyasının Yapısı ve En İyi Uygulamalar

CI/CD sürecinin kalbi .gitlab-ci.yml dosyasıdır. Bu dosya, pipeline aşamalarını, job tanımlarını ve koşulları belirler. Dosyanın temel yapısı şu şekildedir:

stages:
  - test
  - build
  - deploy

variables:
  IMAGE_TAG: "$CI_COMMIT_SHORT_SHA"

test_job:
  stage: test
  script:
    - echo "Running unit tests"
    - npm test
  only:
    - branches

build_job:
  stage: build
  script:
    - echo "Building Docker image"
    - docker build -t myapp:$IMAGE_TAG .
  only:
    - main

deploy_job:
  stage: deploy
  script:
    - echo "Deploying to production"
    - ./deploy.sh
  when: manual
  only:
    - tags

En iyi uygulamalar arasında cache kullanımı, artifacts ile test raporları paylaşma ve environment tanımlamaları yer alır. Örneğin, cache: paths: - node_modules/ eklemek, bağımlılıkların her job’da yeniden indirilmesini önler ve pipeline süresini %30’a kadar kısaltır.

Yaygın Hatalar ve Maliyetleri: Nasıl Önlenir?

GitLab CI/CD’yi ilk kez kuran ekipler genellikle üç ana hatayla karşılaşır: aşırı kaynak tüketimi, yanlış koşul tanımlamaları ve güvenlik açıkları. Aşırı kaynak tüketimi, özellikle paylaşımlı VDS ortamlarında job’ların aynı anda çalışmasıyla ortaya çıkar; bu durum CPU ve bellek sınırlarını aşarak pipeline başarısızlığı ve ek maliyet doğurur. Çözüm olarak, runner’ları tags ile etiketleyip, job’ları belirli runner’lara yönlendirebilirsiniz.

Yanlış koşul tanımlamaları (örneğin only: master yerine only: main) pipeline’ın beklenmedik şekilde atlanmasına sebep olur. Bu durum, hatalı kodun prod’a geçmesini ve olası geri dönüş maliyetlerini artırır. Koşulları test ortamında dry-run yaparak doğrulamak bu riski azaltır.

Güvenlik açısından, runner’ların Docker executor kullanması durumunda privileged modunun gereksiz yere etkinleştirilmesi kritik bir zafiyettir. Bu, konteyner içinde root erişimi sağlayarak sunucuya zarar verebilir. privileged: false tutmak ve sadece ihtiyaç duyulan işlerde ayrı bir güvenli runner oluşturmak en sağlıklı yaklaşımdır.

Gerçek Dünya Senaryosu: Mikroservis Tabanlı Bir Uygulamanın CI/CD Süreci

Bir e‑ticaret platformu, e-ticaret hosting hizmetiyle birlikte mikroservis mimarisi kullanıyor. Her mikroservis ayrı bir GitLab projesinde tutuluyor ve ortak bir Docker registry’ye push ediliyor. Pipeline şu adımları izliyor:

• Test aşaması: Her servis için unit ve entegrasyon testleri çalıştırılıyor; başarısız olanlar pipeline’ı durduruyor.
• Build aşaması: Docker imajları oluşturulup registry.gitlab.com/yourgroup/servicename:$CI_COMMIT_SHA etiketiyle registry’ye push ediliyor.
• Staging deploy: docker‑compose -f docker-compose.staging.yml up -d komutu ile test ortamına otomatik dağıtım yapılıyor.
• Production onay: when: manual ile prod ortamına geçiş onayı alınıyor; onaylandığında aynı imajlar prod’a aktarılıyor.

Bu senaryoda, CI/CD sayesinde kod değişikliği sonrası ortamlar arası tutarlılık %99,9 seviyesine ulaşıyor ve geri dönüş süresi dakikalar içinde gerçekleşiyor. Ayrıca, Docker imajlarının versiyonlanması sayesinde eski sürümlere hızlıca geri dönmek mümkün.

GitLab CI/CD ve Diğer CI Araçları Karşılaştırma Tablosu

Tablodan da görüleceği gibi, GitLab CI/CD özellikle entegrasyon ve güvenlik özellikleriyle öne çıkıyor. Ancak, mevcut altyapınıza ve ekip tercihinize göre diğer araçlar da değerlendirilebilir.

GitLab CI/CD’yi Ölçeklendirme ve Performans İyileştirme İpuçları

CI/CD süreçlerini büyütürken performans kritik bir faktördür. İlk adım, parallel jobs kullanarak testleri paralel çalıştırmaktır; bu, test süresini %50’ye kadar azaltabilir. İkinci adım, cache ve artifact stratejilerini akıllıca belirlemek; örneğin, derleme çıktıları bir sonraki aşamada yeniden kullanılabilir.

Üçüncü adım, runner’ları coğrafi olarak dağıtmaktır. Türkiye’deki ekipleriniz için veri merkezimiz içinde konumlandırılmış VDS’ler düşük gecikme sağlar. Dördüncü adım, SLA hizmeti ile runner’ların uptime garantisini almak; böylece pipeline’lar kesintisiz çalışır.

Son olarak, monitoring entegrasyonu (Prometheus + Grafana) ile job süresi, kaynak tüketimi ve hata oranlarını izleyin. Bu veriler, darboğazları tespit edip optimize etmenize yardımcı olur.

Sıkça Sorulan Sorular

GitLab Runner nedir ve nerede çalıştırılabilir?

GitLab Runner, CI/CD job’larını yürütmek için kullanılan bir ajan programıdır. Docker, Shell, Kubernetes gibi farklı executor tipleriyle çalışabilir ve kendi sunucularınızda (örneğin VDS) ya da GitLab’ın paylaşımlı runner’ları üzerinden kullanılabilir.

.gitlab-ci.yml dosyasında değişken tanımlamak güvenli mi?

Evet, variables bölümü içinde tanımlanan değişkenler pipeline içinde kullanılabilir. Ancak hassas bilgiler (API anahtarları, şifreler) için CI/CD Settings → Variables kısmında “protected” ve “masked” seçeneklerini işaretlemek gerekir.

Pipeline’da “when: manual” ne zaman tercih edilmelidir?

Manuel tetikleme, prod ortamına geçiş gibi kritik adımlarda kontrol sağlamak için idealdir. Böylece otomatik test ve build sonrası, yöneticinin onayıyla dağıtım gerçekleşir ve hatalı sürümün prod’a gitmesi önlenir.

GitLab CI/CD ile Docker imajlarını nasıl güvenli bir şekilde saklarım?

Docker imajlarını GitLab Container Registry’de saklayabilirsiniz. Registry’ye erişim için CI_REGISTRY_USER ve CI_REGISTRY_PASSWORD değişkenlerini kullanın. Ayrıca, imaj taraması için GitLab’ın yerleşik SAST/Container Scanning özelliklerini etkinleştirin.

Sonuç ve Bir Sonraki Adımınız

GitLab CI/CD, kod kalitesini artırırken dağıtım sürecini otomatikleştirerek ekip verimliliğini %30‑%40 arasında yükseltir. Bu makalede ele aldığımız 7 adımlık kurulum, .gitlab-ci.yml optimizasyonları ve ölçeklendirme ipuçları sayesinde, kendi CI/CD boru hattınızı kısa sürede hayata geçirebilirsiniz. Şimdi, kurumsal hosting planınızı gözden geçirip uygun bir VDS seçin, runner’ı kurun ve ilk pipeline’ınızı çalıştırın. Başarılı bir CI/CD süreci, sadece kodunuzu değil, işinizi de geleceğe taşıyacaktır.