# Питання на співбесіді з CI/CD Pipeline: GitHub Actions, GitLab CI та Jenkins у 2026 році

> Підготовка до співбесіди з CI/CD: ключові питання про GitHub Actions, GitLab CI та Jenkins з прикладами коду та порівняльною таблицею для DevOps-інженерів у 2026 році.

- Published: 2026-05-18
- Updated: 2026-05-18
- Author: SharpSkill
- Tags: devops, ci-cd, github-actions, gitlab-ci, jenkins, interview
- Reading time: 12 min

---

Безперервна інтеграція та безперервне розгортання (CI/CD) залишаються фундаментом сучасної розробки програмного забезпечення. Компанії очікують від кандидатів на DevOps-позиції не лише теоретичних знань, а й глибокого розуміння конкретних інструментів — GitHub Actions, GitLab CI та Jenkins. Кожна з цих платформ має власну філософію, синтаксис конфігурації та підхід до оркестрації пайплайнів.

У цій статті розглядаються найпоширеніші питання на співбесідах з CI/CD у 2026 році, з реальними прикладами конфігурацій та детальним порівнянням трьох провідних платформ. Матеріал допоможе систематизувати знання та підготуватися до технічних інтерв'ю будь-якого рівня складності.

> CI/CD-пайплайни — це не просто автоматизація збірки. На співбесідах оцінюють здатність кандидата проєктувати надійні, безпечні та масштабовані конвеєри розгортання. Варто приділити особливу увагу питанням безпеки, паралелізму та стратегіям ручного затвердження.

## Як влаштований CI/CD-пайплайн: базові концепції

Перш ніж переходити до конкретних платформ, на співбесідах часто перевіряють розуміння загальної архітектури CI/CD. Типове питання звучить так: «Опишіть етапи стандартного CI/CD-пайплайну та їхнє призначення».

Класичний пайплайн складається з кількох послідовних етапів. На першому відбувається валідація коду — лінтинг та статичний аналіз. Далі запускаються автоматизовані тести: юніт-тести, інтеграційні, а іноді й end-to-end. Після успішного проходження тестів виконується збірка артефактів. Фінальний етап — розгортання на цільове середовище, часто з ручним затвердженням для продакшену.

Ключовий принцип: кожен наступний етап виконується лише після успішного завершення попереднього. Це гарантує, що в продакшен потрапляє тільки перевірений код.

## GitHub Actions: питання та приклади конфігурації

GitHub Actions став домінантною CI/CD-платформою для проєктів з відкритим кодом та комерційних команд, що використовують GitHub. На співбесідах часто запитують про структуру workflow-файлу, стратегію матричних збірок та механізм залежностей між джобами.

Типове питання: «Напишіть GitHub Actions workflow, який виконує лінтинг, тестування на кількох версіях Node.js та деплоїть лише з гілки main із ручним затвердженням».

```yaml
# .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
```

Розбираючи цю конфігурацію, варто звернути увагу на кілька важливих аспектів. Ключове слово `needs` визначає залежність між джобами: тести запускаються лише після успішного лінтингу. Блок `strategy.matrix` дозволяє запускати тести паралельно на різних версіях Node.js. Директива `environment: production` активує механізм ручного затвердження через required reviewers, налаштованих у репозиторії.

Додаткове питання, яке часто ставлять: «Як працює кешування в GitHub Actions?» Параметр `cache: npm` у дії `actions/setup-node` автоматично кешує директорію `~/.npm`, що значно прискорює встановлення залежностей при повторних запусках.

## GitLab CI: структура пайплайну та артефакти

GitLab CI вирізняється тісною інтеграцією з платформою GitLab та стадійною моделлю виконання. На співбесідах перевіряють знання специфічних концепцій: стадій, правил запуску, артефактів та механізму кешування.

Поширене питання: «Чим відрізняється модель виконання GitLab CI від GitHub Actions та як налаштувати паралельне тестування з артефактами?»

```yaml
# .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 стадії виконуються послідовно, а джоби в межах однієї стадії — паралельно. Це принципова відмінність від GitHub Actions, де джоби за замовчуванням паралельні, а послідовність забезпечується через `needs`.

Важливим аспектом є система артефактів. Блок `artifacts.reports.junit` дозволяє GitLab парсити результати тестів та відображати їх безпосередньо в merge request. Параметр `expire_in: 7 days` контролює час зберігання артефактів, що критично для управління дисковим простором.

Директива `when: manual` створює ручний шлюз перед деплоєм у продакшен. На відміну від GitHub Actions, де ручне затвердження налаштовується через environment protection rules, у GitLab це вбудована функціональність на рівні конфігурації пайплайну.

## Jenkins: декларативний пайплайн та плагіни

Jenkins залишається популярним вибором для великих корпорацій з високими вимогами до контролю інфраструктури. На співбесідах перевіряють знання декларативного синтаксису Jenkinsfile, паралельного виконання та механізму post-обробки.

Класичне питання: «Напишіть Jenkinsfile з паралельним виконанням лінтингу та тестів, ручним затвердженням деплою та сповіщеннями при невдачі».

```groovy
// 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 — повний контроль над інфраструктурою. Директива `tools` посилається на глобально налаштований інструмент, а `credentials()` безпечно витягує секрети зі сховища Jenkins. Блок `parallel` забезпечує одночасне виконання лінтингу та тестів, скорочуючи загальний час пайплайну.

Директива `input` створює інтерактивний шлюз: пайплайн зупиняється та чекає на підтвердження від оператора. Блок `post { failure { ... } }` забезпечує автоматичне сповіщення команди електронною поштою у разі невдалої збірки.

## Порівняння платформ: що запитують на співбесідах

Одне з найпопулярніших питань на технічних інтерв'ю: «Порівняйте GitHub Actions, GitLab CI та Jenkins за ключовими параметрами». Детальне порівняння наведено в таблиці нижче.

| Характеристика | GitHub Actions | GitLab CI | Jenkins |
|---|---|---|---|
| Файл конфігурації | `.github/workflows/*.yml` | `.gitlab-ci.yml` | `Jenkinsfile` |
| Модель виконання | На основі джобів (паралельно за замовчуванням) | На основі стадій (послідовні стадії) | На основі стадій (гнучка) |
| Хостинг раннерів | GitHub-hosted + self-hosted | GitLab.com shared + self-hosted | Тільки self-hosted |
| Зберігання секретів | Секрети репозиторію/організації/середовища | CI/CD-змінні (захищені) | Плагін Credentials |
| Матричні збірки | `strategy.matrix` | `parallel:matrix` | `matrix` (плагін) |
| Ручне затвердження | `environment` + required reviewers | `when: manual` | Директива `input` |
| Маркетплейс | 20 000+ Actions на Marketplace | Каталог CI/CD Components | 1 800+ плагінів |
| AI-функціональність | Copilot for Actions (попередній перегляд) | Duo CI Expert Agent (бета) | Плагіни спільноти |
| Ціноутворення | Безплатно для публічних репо, поминутна оплата для приватних | 400 CI/CD-хвилин безплатно, далі тарифи | Безплатно (відкритий код), самостійне обслуговування |

При відповіді на це питання важливо не просто перелічити відмінності, а продемонструвати розуміння того, коли яка платформа є оптимальним вибором. GitHub Actions ідеально підходить для команд, що вже працюють на GitHub, завдяки нативній інтеграції. GitLab CI — найкращий вибір при потребі в єдиній платформі для всього циклу DevOps. Jenkins залишається незамінним у корпоративних середовищах зі складними вимогами до безпеки та кастомізації.

## Безпека CI/CD-пайплайнів: критичні питання

Безпека пайплайнів — тема, яка набуває все більшої ваги на співбесідах у 2026 році. Типове питання: «Як забезпечити безпеку supply chain у CI/CD-пайплайні?»

Одна з ключових практик — пінінг залежностей до конкретного SHA-комміту замість тегів версій:

```yaml
# .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
```

Тег `v4` може бути переміщений на шкідливий комміт без відома користувача. Фіксація на конкретний SHA-хеш гарантує, що виконується саме той код, який було перевірено. Ця практика стала індустріальним стандартом після резонансних атак на supply chain у попередні роки.

Додаткові аспекти безпеки, які варто знати для співбесіди: принцип найменших привілеїв для GITHUB_TOKEN, використання OIDC для аутентифікації з хмарними провайдерами замість довгоживучих секретів, регулярний аудит використовуваних дій та плагінів, а також ізоляція середовищ через окремі раннери для продакшен-деплоїв.

## Просунуті теми: що відрізняє Senior-кандидатів

На співбесідах для позицій рівня Senior та Lead додатково перевіряють знання просунутих концепцій. Серед них: стратегії розгортання (blue-green, canary, rolling), організація монорепозиторіїв з умовним запуском пайплайнів, оптимізація часу виконання через кешування та паралелізацію, моніторинг та метрики CI/CD (DORA metrics), а також GitOps-підходи з ArgoCD або Flux.

Окремо варто підготуватися до питань про відмовостійкість: «Що відбувається, якщо деплой завершився невдало?» Очікується опис стратегії автоматичного відкату, health checks після деплою та механізмів оповіщення.

## Стратегія підготовки до співбесіди

Ефективна підготовка до співбесіди з CI/CD передбачає не лише вивчення синтаксису конфігурацій, а й практичний досвід. Рекомендується створити тестовий проєкт та налаштувати пайплайни на всіх трьох платформах, порівнюючи підходи на практиці.

Для поглибленого вивчення окремих тем корисними будуть такі матеріали:
- [Основи CI/CD](/technologies/devops/interview-questions/ci-cd-fundamentals) — фундаментальні концепції безперервної інтеграції та розгортання
- [GitHub Actions](/technologies/devops/interview-questions/github-actions) — детальний розбір платформи GitHub
- [GitLab CI](/technologies/devops/interview-questions/gitlab-ci) — поглиблене вивчення GitLab CI/CD
- [Jenkins](/technologies/devops/interview-questions/jenkins) — специфіка роботи з Jenkins
- [Ключові питання на DevOps-співбесіді](/blog/devops/essential-devops-interview-questions) — ширший контекст DevOps-підготовки

## Висновок

- GitHub Actions є оптимальним вибором для команд, що працюють у GitHub-екосистемі, завдяки нативній інтеграції, розвинутому маркетплейсу та простоті налаштування
- GitLab CI забезпечує найтіснішу інтеграцію CI/CD із системою контролю версій, включаючи вбудоване сканування безпеки та управління артефактами
- Jenkins пропонує максимальну гнучкість та повний контроль над інфраструктурою, але потребує більших ресурсів на обслуговування та адміністрування
- Безпека supply chain стала обов'язковою темою на співбесідах у 2026 році — пінінг до SHA, ротація секретів та принцип найменших привілеїв є ключовими концепціями
- Практичний досвід написання пайплайнів на всіх трьох платформах значно підвищує шанси на успішне проходження технічного інтерв'ю
- Знання просунутих тем — DORA-метрик, GitOps, стратегій розгортання — відрізняє кандидатів рівня Senior від Junior та Middle

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/uk/blog/devops/ci-cd-pipeline-interview-questions-github-actions-gitlab-ci-jenkins