GitLab CI/CD Pipeline Oluşturma Rehberi

GitLab CI/CD Nedir ve Neden Kullanmalıyız?

Modern yazılım geliştirme süreçlerinin kalbinde otomasyon yatar. Sürekli Entegrasyon (CI) ve Sürekli Teslimat/Dağıtım (CD) (Continuous Integration/Continuous Delivery/Deployment), geliştiricilerin kod değişikliklerini daha hızlı, güvenli ve güvenilir bir şekilde entegre etmelerini, test etmelerini ve dağıtmalarını sağlayan bir dizi pratiği ifade eder.

GitLab CI/CD, GitLab platformuna tamamen entegre edilmiş güçlü bir otomasyon aracıdır. Projenizin ana dizininde bulunan basit bir .gitlab-ci.yml dosyası ile build, test, lint, güvenlik taraması ve dağıtım gibi tüm adımları otomatikleştirebilirsiniz. Bu entegrasyon sayesinde, kodunuzu değiştirdiğiniz anda pipeline’ınız otomatik olarak çalışır ve size anında geri bildirim sağlar.

GitLab CI/CD Kullanmanın Avantajları:

• Entegrasyon: GitLab kaynak kod yönetimi, CI/CD ve diğer DevOps araçlarını tek bir platformda birleştirir.
• Hız ve Verimlilik: Manuel süreçleri ortadan kaldırarak geliştirme hızını artırır ve hataları erken aşamada tespit eder.
• Tutarlılık: Her zaman aynı adımların takip edilmesini sağlayarak dağıtım süreçlerinde tutarlılık garanti eder.
• Güvenilirlik: Otomatik testler sayesinde üretim ortamına daha güvenilir kod dağıtılmasını sağlar.
• Geri Bildirim: Kod değişikliklerinizin etkileri hakkında anında geri bildirim alırsınız.

Temel Kavramlar: GitLab CI/CD Anatomisi

Bir GitLab CI/CD pipeline’ı oluşturmadan önce bazı temel kavramları anlamak önemlidir:

• .gitlab-ci.yml: Bu dosya, GitLab CI/CD pipeline’ınızın kalbidir. Projenizin kök dizininde bulunur ve tüm CI/CD mantığını (aşamalar, işler, komutlar) YAML formatında tanımlar.
• Pipeline: Kodunuzda bir değişiklik (commit) yapıldığında veya bir merge request açıldığında tetiklenen üst düzey süreçtir. Bir veya daha fazla aşamadan oluşur.
• Stages (Aşamalar): Pipeline’daki mantıksal gruplamalardır. Aşamalar sırayla yürütülür ve bir aşamadaki tüm işler tamamlanmadan bir sonraki aşamaya geçilmez. Örneğin: build, test, deploy.
• Jobs (İşler): Bir aşama içinde çalışan temel birimlerdir. Her iş, bir dizi komut (script) içerir ve bağımsız olarak yürütülür. İşler aynı aşama içinde paralel olarak çalışabilir.
• Runners (Koşucular): CI/CD işlerini fiziksel olarak yürüten ajanlardır. GitLab’ın kendi shared runner’larını kullanabilir veya kendi özel runner’larınızı (Docker, Kubernetes, SSH üzerinde) kurabilirsiniz.

Adım 1: .gitlab-ci.yml Dosyasını Oluşturma

GitLab projenizin kök dizininde .gitlab-ci.yml adında bir dosya oluşturarak başlayın. İşte temel bir yapı ve basit bir örnek:

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Building the application..."
    - # Uygulamanızı derleme veya paketleme komutları buraya gelir (örn: npm install, mvn package)
    - echo "Application built successfully."
  tags:
    - docker # Bu işin çalışacağı runner etiketini belirtir

test_job:
  stage: test
  script:
    - echo "Running unit tests..."
    - # Testleri çalıştırma komutları buraya gelir (örn: npm test, pytest)
    - echo "All tests passed."
  needs:
    - build_job # Bu işin 'build_job' tamamlandıktan sonra çalışmasını sağlar
  tags:
    - docker

deploy_staging_job:
  stage: deploy
  script:
    - echo "Deploying to staging environment..."
    - # Staging ortamına dağıtım komutları buraya gelir (örn: rsync, kubectl apply)
    - echo "Deployed to staging."
  environment:
    name: staging
    url: https://staging.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "develop"
      when: always
  tags:
    - custom-runner # Belirli bir dağıtım runner'ı kullanmak için

Yukarıdaki örnekte:

• stages: Pipeline’ın build, test ve deploy olmak üzere üç aşaması olduğunu tanımlar.
• build_job, test_job, deploy_staging_job: Her biri birer iş adıdır.
• stage: Her işin hangi aşamaya ait olduğunu belirtir.
• script: İşin içinde çalıştırılacak komutlardır. Her komut yeni bir satırda başlamalıdır.
• tags: İşin hangi runner tarafından çalıştırılacağını belirlemek için kullanılır. Özellikle farklı yeteneklere veya ortamlara sahip runner’larınız varsa faydalıdır.
• needs: Bir işin başka bir işin tamamlanmasını beklemesini sağlar ve bu işler farklı aşamalarda olsa bile bağımlılık yaratır.
• environment: Dağıtım yapılan ortamın adını ve isteğe bağlı olarak URL’sini tanımlar. Bu, GitLab’ın “Ortamlar” bölümünde dağıtımları izlemenize olanak tanır.
• rules: Bir işin ne zaman çalışacağını veya atlanacağını belirlemek için güçlü koşullar tanımlamanızı sağlar. Burada, main veya develop dallarına yapılan commit’lerde staging dağıtımının her zaman çalışacağını belirtiyoruz.

Adım 2: Örnek Bir Uygulama İçin Gelişmiş Pipeline Oluşturma (Node.js Örneği)

Şimdi daha gerçekçi bir senaryo için Node.js tabanlı bir web uygulamasını derleme, test etme ve iki farklı ortama (staging ve production) dağıtma pipeline’ı oluşturalım. Bu örnekte önbellekleme (caching), yapıtlar (artifacts), ortamlar (environments) ve koşullu çalıştırma gibi ileri düzey özellikleri de kullanacağız.

# Genel değişkenler tanımlama
variables:
  APP_NAME: "my-nodejs-app"
  NODE_VERSION: "18.x" # Node.js versiyonunu buradan yönetebiliriz

# Pipeline aşamalarını tanımlama
stages:
  - build
  - test
  - deploy_staging
  - deploy_production

# node_modules'i önbelleğe alarak sonraki çalıştırmaları hızlandırın
cache:
  paths:
    - node_modules/ # Projenizin kökündeki node_modules klasörünü önbelleğe alır
  key:
    files:
      - package-lock.json # package-lock.json değiştiğinde önbelleği yeniden oluştur

# Bağımlılıkları yükleme ve uygulamayı derleme işi
install_and_build_job:
  stage: build
  image: node:${NODE_VERSION} # Node.js ortamı için Docker imajı kullan
  script:
    - echo "Installing dependencies for ${APP_NAME}..."
    - npm ci --cache .npm --prefer-offline # package-lock.json'a göre temiz yükleme
    - echo "Building application..."
    - npm run build # package.json'daki 'build' script'ini çalıştır
  artifacts:
    paths:
      - dist/ # Derlenen çıktıları (build klasörü) sonraki aşamalar için sakla
    expire_in: 1 hour # Yapıtların ne kadar süreyle saklanacağını belirt
  tags:
    - docker # Bu iş için 'docker' etiketli bir runner kullan

# Testleri çalıştırma işi
test_job:
  stage: test
  image: node:${NODE_VERSION}
  script:
    - echo "Running unit tests for ${APP_NAME}..."
    - npm ci --cache .npm --prefer-offline # Testler için bağımlılıkları tekrar yükle veya önbelleği kullan
    - npm test # package.json'daki 'test' script'ini çalıştır
  dependencies:
    - install_and_build_job # Bu işin 'install_and_build_job' tarafından oluşturulan yapıtları kullanmasını sağlar
  tags:
    - docker

# Staging ortamına dağıtım işi
deploy_staging_job:
  stage: deploy_staging
  image: alpine/git # Dağıtım için minimalist bir imaj veya özel bir dağıtım aracı imajı
  script:
    - echo "Deploying ${APP_NAME} to Staging environment..."
    - # Burada staging sunucunuza SFTP, rsync, kubectl, Ansible veya Serverless Framework
    - # gibi araçlarla dağıtım komutlarınızı yazın.
    - echo "Staging deployment completed successfully for ${APP_NAME}."
  environment:
    name: staging
    url: https://staging.${APP_NAME}.com # GitLab UI'da görüntülenecek ortam URL'si
  rules:
    - if: $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "develop"
      when: always # main veya develop dalına yapılan her commit'te çalıştır
  dependencies:
    - install_and_build_job # Derlenmiş uygulamayı kullanmak için
  tags:
    - custom-deploy-runner # Dağıtım için özel bir runner kullanmak isteyebilirsiniz

# Üretim ortamına manuel dağıtım işi
deploy_production_job:
  stage: deploy_production
  image: alpine/git
  script:
    - echo "Deploying ${APP_NAME} to Production environment..."
    - # Üretim sunucunuza dağıtım komutları buraya gelir.
    - echo "Production deployment completed successfully for ${APP_NAME}."
  environment:
    name: production
    url: https://${APP_NAME}.com
  when: manual # Bu işin GitLab UI üzerinden manuel olarak tetiklenmesini sağlar
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual # Sadece 'main' dalına yapılan commit'lerde manuel olarak görünür
  dependencies:
    - install_and_build_job # Derlenmiş uygulamayı kullanmak için
  tags:
    - production-runner # Üretim dağıtımları için ayrılmış, güvenli bir runner