GitLab CI/CD Pipeline Oluşturma Rehberi

GitLab CI/CD Pipeline Oluşturma Rehberi

Giriş

Modern yazılım geliştirme süreçlerinde hız, güvenilirlik ve tutarlılık hayati öneme sahiptir. Bu hedeflere ulaşmanın en etkili yollarından biri de Sürekli Entegrasyon (CI) ve Sürekli Dağıtım/Teslimat (CD) pratiklerini uygulamaktır. GitLab CI/CD, GitLab platformuna entegre edilmiş güçlü ve esnek bir araçtır. Projelerinizin kod tabanındaki değişiklikleri otomatik olarak test etmenize, oluşturmanıza ve dağıtmanıza olanak tanır.

Bu rehber, bir GitLab projesi için temel bir CI/CD pipeline’ını adım adım nasıl oluşturacağınızı, yapılandıracağınızı ve çalıştıracağınızı açıklamaktadır. Amacımız, projelerinizin geliştirme yaşam döngüsünü otomatikleştirmeye başlamanız için sağlam bir temel sunmaktır.

Kurulum Adımları

GitLab CI/CD pipeline’ı oluşturmaya başlamak için birkaç ön koşul ve temel kurulum adımı bulunmaktadır:

1. GitLab Projesi Oluşturma veya Mevcut Projeyi Kullanma

Öncelikle, CI/CD pipeline’ını uygulayacağınız bir GitLab projeniz olmalıdır. Eğer mevcut bir projeniz yoksa, GitLab üzerinde yeni bir proje oluşturabilirsiniz.

2. GitLab Runner’ı Anlama ve Doğrulama

GitLab CI/CD pipeline’ındaki işleri (job) çalıştıran servislere GitLab Runner denir. Runner’lar, kodunuzu derlemek, test etmek ve dağıtmak için gerekli ortamı sağlar. GitLab projeleri genellikle aşağıdaki runner türlerinden birini kullanır:

• Paylaşımlı Runner’lar (Shared Runners): GitLab.com tarafından sağlanan ve birçok proje tarafından kullanılan genel runner’lardır. Başlangıç için harika bir seçenektir.
• Spesifik Runner’lar (Specific Runners): Projenize özel olarak veya grubunuza özel olarak kurduğunuz runner’lardır. Daha fazla kontrol ve özel bağımlılıklar gerektiren durumlar için idealdir.

Projenizin Ayarlar > CI/CD > Runner’lar bölümünden projenizle ilişkilendirilmiş aktif bir runner’ın olup olmadığını kontrol edin. Paylaşımlı runner’lar genellikle varsayılan olarak aktiftir.

3. `.gitlab-ci.yml` Dosyası Oluşturma

CI/CD pipeline’ınızın tüm yapılandırması, projenizin kök dizininde bulunan .gitlab-ci.yml adlı bir YAML dosyası aracılığıyla tanımlanır. Bu dosyayı projenizin kök dizinine ekleyerek pipeline’ınızı başlatırsınız.

# .gitlab-ci.yml dosyasını projenizin kök dizininde oluşturun
# İlk başta boş olabilir, içerik ekledikçe pipeline aktifleşecektir.

Yapılandırma: .gitlab-ci.yml Dosyası

Şimdi .gitlab-ci.yml dosyasının temel yapısına ve sık kullanılan anahtar kelimelere göz atalım. Bir pipeline temel olarak aşamalar (stages) ve işlerden (jobs) oluşur.

1. Aşamalar (Stages)

Aşamalar, pipeline’ınızdaki işlerin mantıksal gruplandırılmasıdır. İşler, aynı aşama içinde paralel olarak çalışırken, farklı aşamalardaki işler sırayla çalışır. Örneğin, genellikle bir “build”, “test” ve “deploy” aşaması tanımlanır.

stages:
  - build
  - test
  - deploy

Yukarıdaki örnekte, build aşamasındaki tüm işler tamamlanmadan test aşamasına geçilmeyecek, test aşaması bitmeden de deploy aşamasına başlanmayacaktır.

2. İşler (Jobs)

İşler, bir pipeline’ın temel yapı taşlarıdır. Her iş, bir aşamaya aittir ve belirli bir dizi komutu çalıştırır. Bir işi tanımlarken kullanabileceğiniz bazı temel anahtar kelimeler:

• image: İşin çalışacağı Docker imajını belirtir. Bu, iş için izole bir ortam sağlar. (Örn: node:16-alpine, python:3.9-slim, maven:3.8.1-jdk-11)
• stage: İşin hangi aşamada çalışacağını belirtir. Yukarıda tanımladığınız aşamalardan biri olmalıdır.
• script: İşin çalıştıracağı kabuk komutlarının listesidir. Bu komutlar sırasıyla yürütülür.
• before_script: script bölümünden önce her iş için çalışacak komutlar. Bağımlılıkları yüklemek gibi genel kurulum adımları için kullanışlıdır.
• after_script: İş tamamlandıktan sonra (başarılı veya başarısız) çalışacak komutlar. Temizlik işlemleri için kullanılabilir.
• only / except: İşin hangi Git branch’lerinde veya etiketlerinde çalışacağını veya çalışmayacağını kontrol eder. (Örn: only: - main)
• artifacts: Bir işten sonra saklanacak veya sonraki işlere aktarılacak dosyaları veya dizinleri tanımlar. (Örn: build çıktıları)
• cache: İşler arasında bağımlılıkları (örn: npm paketleri, Maven depoları) önbelleğe alarak pipeline çalışma sürelerini hızlandırır.
• needs: Bir işin, diğer işlerin başarıyla tamamlanmasına bağımlı olduğunu belirtir. Bu, aşama sıralamasından bağımsız olarak işlerin paralel çalışmasını sağlayabilir.

3. Örnek Bir CI/CD Pipeline

Şimdi basit bir web projesi için (HTML dosyası oluşturan) temel bir “build”, “test” ve “deploy” pipeline’ı oluşturalım. Bu örnekte, alpine/git gibi hafif bir Docker imajı kullanarak işlem yapacağız.

a. Build Aşaması (Build Stage)

Bu aşama, projenin derlenmesi veya derlemeye benzer çıktıların oluşturulması ile ilgilidir. Örneğimizde, basit bir HTML dosyası oluşturacağız.

build_job:
  stage: build
  image: alpine/git # Build işlemi için minimal bir image
  script:
    - echo "Proje oluşturuluyor..."
    - mkdir public
    - echo "<h1>Merhaba GitLab CI/CD!</h1><p>Bu bir deneme build çıktısıdır.</p>" > public/index.html
  artifacts:
    paths:
      - public # public klasöründeki çıktıları kaydet
    expire_in: 1 hour # Çıktıları 1 saat sonra sil

Yukarıdaki iş:

• build aşamasında çalışır.
• alpine/git Docker imajını kullanır.
• public adında bir dizin oluşturur ve içine bir index.html dosyası yazar.
• artifacts anahtar kelimesiyle public dizinindeki tüm dosyaları pipeline’ın sonraki aşamalarında kullanılmak üzere veya manuel indirme için saklar.

b. Test Aşaması (Test Stage)

Bu aşama, oluşturulan çıktının veya kodun test edilmesini sağlar. Örneğimizde, önceki aşamada oluşturulan HTML dosyasının varlığını basitçe kontrol edeceğiz.

test_job:
  stage: test
  image: alpine/git # Test işlemi için aynı veya farklı bir image kullanabilirsiniz
  script:
    - echo "Testler başlatılıyor..."
    - ls -la public/ # Build çıktısının geldiğini doğrulamak için
    - test -f public/index.html || { echo "Build çıktısı bulunamadı!"; exit 1; }
    - echo "Testler başarıyla tamamlandı."
  needs: ["build_job"] # Bu işin build_job'ın artifacts'ına ihtiyacı var

Yukarıdaki iş:

• test aşamasında çalışır.
• build_job‘dan gelen artifacts‘a erişebilir.
• public/index.html dosyasının varlığını kontrol eder. Yoksa işi başarısız yapar.
• needs: ["build_job"] ile bu işin `build_job`’a bağımlı olduğunu belirtir, bu sayede `build_job`’ın çıktısı bu iş için de kullanılabilir.

c. Deploy Aşaması (Deploy Stage)

Bu aşama, testlerden geçen uygulamanın hedef ortamlara (geliştirme, hazırlık, üretim) dağıtılmasını içerir. Örneğimizde, basit bir dağıtım mesajı göstereceğiz ve sadece main branch’ine push edildiğinde çalışmasını sağlayacağız.

deploy_job:
  stage: deploy
  image: alpine/git
  script:
    - echo "Uygulama sunucuya dağıtılıyor..."
    - ls -la public/ # Dağıtılacak dosyaları kontrol edelim
    - echo "public/index.html dosyası üretim ortamına dağıtıldı."
    - echo "Dağıtım başarılı!"
  only:
    - main # Sadece 'main' branch'ine push edildiğinde bu işi çalıştır
  needs: ["test_job"] # Bu işin test_job'ın başarıyla tamamlanmasına ihtiyacı var

Yukarıdaki iş:

• deploy aşamasında çalışır.
• Sadece main branch’indeki değişiklikler için tetiklenir.
• test_job‘dan gelen artifacts‘a erişebilir.
• Basit bir dağıtım mesajı gösterir. Gerçek senaryoda buraya SSH, FTP, Kubernetes dağıtım komutları vb. eklenecektir.

4. Tam Pipeline Kodu (`.gitlab-ci.yml`)

Tüm bu işleri bir araya getirerek elde edeceğimiz nihai .gitlab-ci.yml dosyası şöyle görünmelidir:

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  image: alpine/git
  script:
    - echo "Proje oluşturuluyor..."
    - mkdir public
    - echo "<h1>Merhaba GitLab CI/CD!</h1><p>Bu bir deneme build çıktısıdır.</p>" > public/index.html
  artifacts:
    paths:
      - public
    expire_in: 1 hour

test_job:
  stage: test
  image: alpine/git
  script:
    - echo "Testler başlatılıyor..."
    - ls -la public/
    - test -f public/index.html || { echo "Build çıktısı bulunamadı!"; exit 1; }
    - echo "Testler başarıyla tamamlandı."
  needs: ["build_job"]

deploy_job:
  stage: deploy
  image: alpine/git
  script:
    - echo "Uygulama sunucuya dağıtılıyor..."
    - ls -la public/
    - echo "public/index.html dosyası üretim ortamına dağıtıldı."
    - echo "Dağıtım başarılı!"
  only:
    - main
  needs: ["test_job"]

Bu dosyayı projenizin kök dizinine kaydedin ve bir commit ile GitLab’a push edin. GitLab, dosyadaki talimatları otomatik olarak algılayacak ve pipeline’ı çalıştıracaktır. Pipeline’ın durumunu GitLab projenizdeki CI/CD > Pipelines bölümünden takip edebilirsiniz.

Sonuç

Bu rehberde, GitLab CI/CD’nin temellerini öğrendik ve basit bir web projesi için üç aşamalı (build, test, deploy) bir pipeline oluşturduk. Artık kod değişikliklerinizi otomatik olarak derleyen, test eden ve dağıtan bir sisteminiz var.

GitLab CI/CD, burada gösterilenlerden çok daha fazla yeteneğe sahiptir. Pipeline’ınızı daha da güçlendirmek için keşfedebileceğiniz bazı ileri konular şunlardır:

• Ortamlar (Environments): Dağıtımları farklı ortamlara (geliştirme, hazırlık, üretim) yönetme.
• Değişkenler (Variables): Hassas bilgileri veya tekrar eden değerleri güvenli bir şekilde saklama ve kullanma.
• Kurallar (Rules): İşlerin ne zaman çalışacağını daha detaylı kontrol etme.
• Paralel İşler (Parallel Jobs): Testleri veya derleme adımlarını aynı anda birden fazla runner’da çalıştırma.
• Güvenlik Taramaları (SAST, DAST, Dependency Scanning): Kodunuzdaki güvenlik açıklarını otomatik olarak bulma.
• Monorepo Desteği: Büyük projelerde farklı servislerin veya uygulamaların pipeline’larını yönetme.

CI/CD otomasyonu, geliştirme sürecinizi önemli ölçüde hızlandırır, hataları azaltır ve ekipler arası işbirliğini güçlendirir. Bu başlangıç rehberiyle edindiğiniz bilgileri kullanarak, projeleriniz için daha karmaşık ve güçlü pipeline’lar oluşturmaya başlayabilirsiniz. İyi kodlamalar!