CI/CD Pipeline Mülakat Soruları: 2026'da GitHub Actions, GitLab CI ve Jenkins

DevOps mühendisliği mülakatlarında CI/CD pipeline bilgisi artık temel bir beklenti haline geldi. 2026 itibarıyla şirketler, adaylardan yalnızca kavramsal bilgi değil, GitHub Actions, GitLab CI ve Jenkins gibi araçları pratikte yapılandırabilme yetkinliği bekliyor. Bu rehber, mülakatlarda en sık karşılaşılan CI/CD sorularını gerçek yapılandırma örnekleriyle birlikte ele alıyor.

CI/CD Pipeline Nedir ve Neden Sorulur?

CI/CD (Continuous Integration / Continuous Delivery), yazılım değişikliklerinin otomatik olarak test edilmesi, doğrulanması ve dağıtılması sürecini tanımlar. Bir CI/CD pipeline, bu sürecin adım adım tanımlandığı otomatik bir iş akışıdır.

Mülakatlarda bu konunun sıkça sorulmasının birkaç temel nedeni vardır. Birincisi, CI/CD pipeline tasarımı bir adayın yazılım teslimat süreçlerini ne kadar iyi anladığını ortaya koyar. İkincisi, pipeline yapılandırması güvenlik, performans ve maliyet optimizasyonu gibi çapraz disiplin bilgisi gerektirir. Son olarak, modern yazılım geliştirme ekiplerinde CI/CD bilgisi olmayan bir mühendis, ekip verimliliğini doğrudan etkiler.

Tipik bir mülakat sorusu şöyle olabilir: "Sıfırdan bir CI/CD pipeline tasarlayın. Lint, test ve deploy aşamalarını içersin. Hangi aracı seçerdiniz ve neden?"

GitHub Actions: Workflow Yapılandırması

GitHub Actions, GitHub ekosistemiyle doğal entegrasyonu sayesinde 2026'da en yaygın kullanılan CI/CD araçlarından biri olmaya devam ediyor. Mülakatlarda GitHub Actions ile ilgili sorular genellikle workflow dosyası yapısı, job bağımlılıkları ve matrix stratejileri etrafında şekilleniyor.

Aşağıdaki örnek, lint, test ve deploy aşamalarını kapsayan eksiksiz bir pipeline yapılandırmasını göstermektedir:

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint              # waits for lint to pass
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]       # runs tests on both versions
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production  # requires approval
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

Bu yapılandırmada dikkat edilmesi gereken birkaç kritik nokta bulunuyor. needs anahtarı job'lar arasında bağımlılık zinciri oluşturur; lint başarısız olursa test çalışmaz. strategy.matrix ile testler birden fazla Node.js sürümünde paralel olarak yürütülür. environment: production tanımı, deploy aşamasında manuel onay gerektiren bir kapı (gate) oluşturur.

Sık sorulan mülakat sorusu: "needs anahtarı olmadan job'lar nasıl çalışır?" Yanıt: GitHub Actions'ta job'lar varsayılan olarak paralel çalışır. needs ile sıralı hale getirilirler.

GitLab CI: Stage Tabanlı Pipeline

GitLab CI, .gitlab-ci.yml dosyasıyla yapılandırılır ve stage tabanlı bir yürütme modeli kullanır. Aynı stage içindeki job'lar paralel çalışırken, stage'ler sıralı olarak ilerler. Bu mimari fark, mülakatlarda GitHub Actions ile karşılaştırmalı olarak sıkça sorulur.

# .gitlab-ci.yml
stages:
  - validate
  - test
  - deploy

variables:
  NODE_VERSION: "22"

lint:
  stage: validate
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm run lint

unit-tests:
  stage: test
  image: node:${NODE_VERSION}
  parallel:
    matrix:
      - NODE_VERSION: ["20", "22"]
  script:
    - npm ci
    - npm test
  artifacts:
    reports:
      junit: coverage/junit.xml
    expire_in: 7 days

deploy-production:
  stage: deploy
  image: alpine:latest
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual                   # manual gate
  environment:
    name: production
    url: https://app.example.com
  script:
    - ./deploy.sh

GitLab CI yapılandırmasında öne çıkan özellikler şunlardır. cache bloğu, node_modules dizinini branch bazında önbelleğe alarak sonraki çalışmaları hızlandırır. artifacts bloğu, test raporlarını JUnit formatında saklar ve bunlar GitLab arayüzünde doğrudan görüntülenebilir. when: manual ifadesi, production ortamına dağıtım için manuel onay gerektirir.

Mülakat ipucu: GitLab CI'da rules ve eski only/except sözdizimi arasındaki fark sıkça sorulur. rules daha esnek ve öngörülebilir bir davranış sunar; 2026'da only/except kullanımı artık önerilmemektedir.

Jenkins: Declarative Pipeline

Jenkins, self-hosted mimarisi ve geniş eklenti ekosistemiyle kurumsal ortamlarda hala yaygın olarak kullanılmaktadır. Mülakatlarda Jenkins soruları genellikle Declarative Pipeline sözdizimi, paralel yürütme ve post-build aksiyonları üzerine yoğunlaşır.

// Jenkinsfile
pipeline {
    agent any

    tools {
        nodejs 'node-22'       // configured in Jenkins Global Tool
    }

    environment {
        CI = 'true'
        DEPLOY_ENV = credentials('deploy-env-secret')
    }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint & Test') {
            parallel {             // parallel execution
                stage('Lint') {
                    steps {
                        sh 'npm run lint'
                    }
                }
                stage('Test') {
                    steps {
                        sh 'npm test'
                    }
                    post {
                        always {
                            junit 'coverage/junit.xml'
                        }
                    }
                }
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            input {
                message 'Deploy to production?'
            }
            steps {
                sh './deploy.sh'
            }
        }
    }

    post {
        failure {
            mail to: 'team@example.com',
                 subject: "Build failed: ${env.JOB_NAME}",
                 body: "Check ${env.BUILD_URL}"
        }
    }
}

Jenkins pipeline yapısında dikkat çeken noktalar arasında parallel bloğu lint ve test aşamalarının eşzamanlı yürütülmesini sağlaması yer alır. credentials() fonksiyonu Jenkins Credentials Plugin ile entegre çalışarak hassas bilgileri güvenli biçimde pipeline'a aktarır. input direktifi deploy aşamasında insan onayı bekler. post bloğu ise pipeline sonucuna göre bildirim gönderir.

Sık sorulan mülakat sorusu: "Declarative ve Scripted Pipeline arasındaki fark nedir?" Declarative Pipeline, pipeline {} bloğu içinde yapılandırılır ve daha kısıtlı ama okunabilir bir sözdizimi sunar. Scripted Pipeline ise tam Groovy esnekliği sağlar ancak karmaşıklığı artırır. Modern Jenkins kullanımında Declarative Pipeline tercih edilir.

Platform Karşılaştırma Tablosu

Mülakatçılar sıklıkla bu üç aracın karşılaştırılmasını ister. Aşağıdaki tablo, temel farklılıkları özetlemektedir:

| Özellik | GitHub Actions | GitLab CI | Jenkins | |---|---|---|---| | Yapılandırma dosyası | .github/workflows/*.yml | .gitlab-ci.yml | Jenkinsfile | | Yürütme modeli | Job tabanlı (varsayılan paralel) | Stage tabanlı (sıralı stage'ler) | Stage tabanlı (esnek) | | Runner barındırma | GitHub-hosted + self-hosted | GitLab.com paylaşımlı + self-hosted | Yalnızca self-hosted | | Gizli bilgi yönetimi | Repository/Org/Environment secrets | CI/CD değişkenleri (korumalı) | Credentials eklentisi | | Matrix build | strategy.matrix | parallel:matrix | matrix (eklenti) | | Manuel onay kapıları | environment + zorunlu inceleyiciler | when: manual | input direktifi | | Market yeri | 20.000+ Action | CI/CD Components Catalog | 1.800+ eklenti | | Yapay zeka özellikleri | Copilot for Actions (önizleme) | Duo CI Expert Agent (beta) | Topluluk eklentileri | | Fiyatlandırma | Açık depolar için ücretsiz, özel depolar dakika başına | 400 CI/CD dakikası ücretsiz, sonra kademeli | Ücretsiz (açık kaynak), kendi yönetimli |

Bu tabloyu ezberlemek yerine, her platformun tasarım felsefesini anlamak daha faydalıdır. GitHub Actions, GitHub ekosistemiyle sıkı entegrasyon sunar. GitLab CI, tek platform yaklaşımıyla SCM ve CI/CD'yi birleştirir. Jenkins ise maksimum esneklik ve kontrol sağlar ancak bakım yükü daha yüksektir.

CI/CD Güvenlik Soruları

2026 mülakatlarında CI/CD güvenliği ayrı bir soru kategorisi olarak karşımıza çıkmaktadır. Supply chain saldırılarının artmasıyla birlikte pipeline güvenliği kritik önem kazanmıştır.

En sık sorulan güvenlik sorusu: "GitHub Actions'ta action pinning nedir ve neden önemlidir?"

# .github/workflows/secure.yml
steps:
  # Vulnerable: tag can be moved to malicious commit
  - uses: actions/checkout@v4

  # Secure: pinned to exact commit SHA
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

Tag tabanlı referanslar (örneğin @v4) değiştirilebilir; saldırgan tag'i kötü amaçlı bir commit'e yönlendirebilir. SHA pinning, tam olarak hangi kodun çalıştırılacağını garanti eder. Bu, supply chain güvenliğinin temel taşlarından biridir.

Mülakatlarda önem taşıyan diğer güvenlik konuları şunlardır:

• Secret yönetimi: Pipeline içinde hassas bilgilerin (API anahtarları, veritabanı şifreleri) nasıl saklandığı ve erişildiği
• Least privilege prensibi: Runner'ların ve job'ların yalnızca ihtiyaç duyduğu izinlere sahip olması
• OIDC token kullanımı: Statik credential'lar yerine kısa ömürlü token'larla bulut servislerine erişim
• Dependency scanning: Pipeline içinde bağımlılıkların güvenlik açıkları için otomatik taranması

Mülakatlarda Sık Sorulan İleri Düzey Sorular

Deneyimli aday mülakatlarında pipeline tasarımı ötesinde, mimari kararları ve trade-off analizleri beklenir. Aşağıda 2026'da sık karşılaşılan ileri düzey sorular yer almaktadır.

"Monorepo için CI/CD pipeline nasıl tasarlanır?"

Monorepo yaklaşımında path-based triggering kritik öneme sahiptir. GitHub Actions'ta paths filtresi, GitLab CI'da rules:changes ve Jenkins'te changeset kullanılarak yalnızca değişen servislerin pipeline'ı tetiklenir. Bu, gereksiz build sürelerini ortadan kaldırır.

"Pipeline sürelerini nasıl optimize edersiniz?"

Optimizasyon stratejileri arasında agresif önbellekleme (dependency cache, Docker layer cache), paralel iş yürütme, artımlı (incremental) build ve test bölme (test splitting) yer alır. Matrix build'ler test kapsamını genişletirken, paralel yürütme toplam süreyi kısaltır.

"Rollback stratejiniz nedir?"

Olgun bir CI/CD sistemi, başarısız bir deploy sonrası otomatik veya yarı-otomatik rollback desteklemelidir. Blue-green deployment, canary release ve feature flag entegrasyonu bu bağlamda tartışılması gereken konulardır.

"GitOps ile geleneksel CI/CD arasındaki fark nedir?"

GitOps, deklaratif altyapı tanımlarını Git deposunda saklar ve bir operatörün (örneğin ArgoCD veya Flux) cluster durumunu repo ile sürekli senkronize etmesini sağlar. Geleneksel CI/CD'de ise pipeline doğrudan deploy komutları çalıştırır. 2026'da Kubernetes ortamlarında GitOps yaklaşımı standart haline gelmiştir.

CI/CD mülakat hazırlığını derinleştirmek için aşağıdaki konuları da incelemek faydalı olacaktır: CI/CD fundamentals temel kavramların detaylı incelemesi, GitHub Actions platforma özel mülakat soruları, GitLab CI GitLab'a özgü yapılandırma detayları, Jenkins Jenkins pipeline ileri düzey konular ve essential DevOps interview questions genel DevOps mülakat rehberi.

Sonuç

• GitHub Actions, GitHub ekosistemiyle doğal entegrasyonu ve geniş marketplace'i ile özellikle açık kaynak projeleri ve GitHub kullanan ekipler için en pratik CI/CD çözümüdür
• GitLab CI, tek platform yaklaşımıyla SCM, CI/CD ve güvenlik taramasını birleştirerek kurumsal ortamlarda güçlü bir alternatif sunar
• Jenkins, tam altyapı kontrolü ve geniş eklenti ekosistemi ile özelleştirilmiş ihtiyaçları olan kuruluşlar için uygun olmaya devam etmektedir, ancak bakım maliyeti yüksektir
• Supply chain güvenliği 2026 mülakatlarında ayrı bir soru kategorisi haline gelmiştir; SHA pinning, secret rotasyonu ve least privilege prensibi mutlaka bilinmelidir
• Pipeline optimizasyonu (önbellekleme, paralelleştirme, koşullu yürütme) pratik deneyim gerektiren ve mülakatlarda somut örneklerle desteklenmesi beklenen bir konudur
• Her üç platformda da çalışan bir pipeline yapılandırması yazabilmek, adayı rekabette öne çıkaran en etkili beceridir