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

Питання про CI/CD pipeline на співбесідах входять до найпоширеніших тем у DevOps-найм у 2026 році. GitHub Actions обробляє понад 71 мільйон завдань на день і випустив паралельне виконання кроків у червні 2026, GitLab CI досягнув версії 19 з вбудованим Secrets Manager, а Jenkins зберігає 28% частку ринку. Рекрутери очікують від кандидатів практичного володіння всіма трьома платформами.

Структура workflow та тригери GitHub Actions

GitHub Actions організовує автоматизацію навколо workflow, jobs та steps. Workflow — це YAML-файл, що зберігається в .github/workflows/ і визначає, коли та як запускається автоматизація. Кожен workflow містить одне або більше завдань, і кожне завдання виконується на окремому runner.

Типове питання на співбесіді просить пояснити зв'язок між тригерами on, залежностями між завданнями та ключовим словом needs.

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

Цей workflow демонструє три ключові концепції: ключове слово needs створює граф залежностей між завданнями, стратегія matrix дозволяє паралельне тестування на різних версіях Node.js, а ключове слово environment вимагає ручного затвердження перед розгортанням.

Паралельні кроки в GitHub Actions

GitHub Actions випустив паралельне виконання кроків 25 червня 2026 року, реалізувавши одну з найбільш запитуваних функцій. Раніше всі кроки в межах завдання виконувалися послідовно. Нова функція вводить чотири ключові слова, що дозволяють паралельне виконання в межах одного завдання.

# .github/workflows/parallel-steps.yml
name: Build with Parallel Steps

on:
  push:
    branches: [main]

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

      # Run lint and typecheck in parallel
      - name: lint
        run: npm run lint
        background: true

      - name: typecheck
        run: npm run typecheck
        background: true

      - wait-all:              # wait for both to complete

      # Or use the parallel shorthand
      - parallel:
          - name: build-frontend
            run: npm run build:frontend
          - name: build-backend
            run: npm run build:backend

      - run: npm run deploy

Ключове слово background: true запускає крок асинхронно і негайно переходить до наступного кроку. Ключове слово wait-all призупиняє виконання до завершення всіх попередніх фонових кроків. Ключове слово parallel забезпечує скорочений синтаксис, що запускає кілька кроків одночасно і чекає завершення всіх перед продовженням.

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

Конфігурація pipeline GitLab CI з етапами

GitLab CI використовує файл .gitlab-ci.yml у кореневому каталозі репозиторію. На відміну від GitHub Actions, де завдання виконуються незалежно за замовчуванням, GitLab CI організовує завдання в етапи, які виконуються послідовно, тоді як завдання в межах одного етапу працюють паралельно.

Рекрутери часто просять кандидатів конвертувати workflow GitHub Actions у pipeline GitLab CI або навпаки.

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

Ключові відмінності від GitHub Actions: етапи забезпечують глобальний порядок виконання, ключове слово parallel:matrix обробляє matrix-збірки, а artifacts:reports:junit інтегрує результати тестів безпосередньо у перегляди merge request.

GitLab 19.0 (травень 2026) представив Secrets Manager у відкритій бета-версії, забезпечуючи нативне зберігання секретів без зовнішніх сервісів, таких як HashiCorp Vault. GitLab 19.2 (липень 2026) зробив політики запланованого виконання pipeline загальнодоступними, дозволяючи командам примусово виконувати сканування відповідності або перевірки залежностей за фіксованим розкладом у кількох проєктах з єдиного визначення політики.

Декларативний синтаксис pipeline Jenkins

Jenkins використовує Jenkinsfile, що зберігається в кореневому каталозі репозиторію. Декларативний синтаксис pipeline, рекомендований як стандарт у 2026 році, забезпечує структуровану обробку помилок та чіткий макет на основі етапів.

Часте питання на співбесіді: поясніть різницю між декларативними та скриптовими pipeline і коли використовувати кожен з них.

// 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}"
        }
    }
}

Декларативні pipeline забезпечують структуру через обов'язкові блоки pipeline, agent та stages. Директива parallel всередині етапу запускає lint і test одночасно. Директива input призупиняє виконання для ручного затвердження, подібно до середовищ GitHub Actions та ручних воріт GitLab. Jenkins вимагає Java 21 з січня 2026 року, тому середовища pipeline повинні враховувати цю залежність runtime.

Керування секретами на CI/CD платформах

Кожна співбесіда з CI/CD включає питання про керування секретами. Кожна платформа обробляє облікові дані по-різному, і розуміння наслідків для безпеки має значення.

GitHub Actions зберігає секрети на рівні репозиторію, середовища або організації. Секрети автоматично маскуються в логах, але поточна модель визначення області має обмеження. Дорожня карта безпеки 2026 вводить секрети з обмеженою областю, які прив'язують облікові дані до явних контекстів виконання, усуваючи ризик надто широкого доступу.

GitLab CI надає змінні CI/CD з правилами захисту. Захищені змінні ін'єктуються лише в pipeline, що працюють на захищених гілках або тегах. GitLab 19.0 представив Secrets Manager, дозволяючи командам зберігати та посилатися на секрети нативно без зовнішніх vault. Секрети обмежені проєктами або групами і доступні лише для завдань, які їх явно запитують.

Jenkins використовує плагін Credentials з кількома типами облікових даних (ім'я користувача/пароль, SSH-ключ, секретний текст, сертифікат). Допоміжна функція credentials() у декларативних pipeline прив'язує секрети до змінних середовища, а облікові дані рівня Folder обмежують доступ до конкретних проєктів.

Ключова відповідь на співбесіді: ніколи не хардкодити секрети у файлах pipeline, завжди використовувати нативне керування секретами платформи, регулярно ротувати облікові дані та віддавати перевагу короткостроковим токенам над довгостроковими API-ключами.

Оптимізація pipeline та стратегії кешування

Повільні pipeline безпосередньо впливають на продуктивність розробників. Рекрутери перевіряють, чи можуть кандидати діагностувати та виправляти вузькі місця продуктивності в CI/CD системах.

Три універсальні техніки оптимізації застосовуються на всіх трьох платформах:

Кешування залежностей уникає повторного завантаження пакетів при кожному запуску. GitHub Actions використовує actions/cache або вбудовану підтримку кешу в setup actions. GitLab CI використовує cache зі стратегією ключів. Jenkins покладається на персистентність workspace або команди stash/unstash.

Паралельне виконання розподіляє роботу між кількома runner. GitHub Actions тепер підтримує як паралельні завдання (стратегія matrix), так і паралельні кроки (ключові слова background/parallel). GitLab CI використовує parallel:matrix, а Jenkins використовує директиву parallel. Правильна гранулярність розподілу залежить від проєкту: занадто багато паралельних завдань витрачає час на запуск runner, занадто мало залишає потужність невикористаною.

Умовне виконання пропускає непотрібні етапи. Усі три платформи це підтримують: GitHub Actions з виразами if, GitLab CI з rules, а Jenkins з директивами when. Добре спроєктований pipeline пропускає етапи розгортання на feature-гілках і пропускає повні набори тестів при змінах, що стосуються лише linting.

Безпека CI/CD pipeline та захист ланцюга постачання

Атаки на ланцюг постачання, націлені на CI/CD системи, значно зросли у 2025 році, з інцидентами, що вплинули на tj-actions/changed-files та інші популярні GitHub Actions. Питання на співбесідах тепер регулярно перевіряють стратегії зміцнення.

Прив'язка версій action до конкретних SHA commit замість тегів запобігає атакам tag-hijacking:

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

GitLab CI вирішує проблеми ланцюга постачання через CI/CD компоненти з атестацією SLSA Level 1 (доступні з GitLab 18.1), забезпечуючи чіткіше походження при складанні pipeline з компонентів для повторного використання. Незмінні теги контейнерів (GitLab 18.2) запобігають заміні образів після публікації.

Для Jenkins механізм Shared Library повинен використовувати виділений репозиторій із захистом гілок, вимогами code review та підписаними commit. Європейська Комісія запустила програму Bug Bounty для Jenkins через YesWeHack, що відображає критичну роль платформи в корпоративних ланцюгах постачання.

Міжплатформне порівняння для підготовки до співбесіди

Ця таблиця порівняння охоплює найчастіше тестовані відмінності на співбесідах. Наступне питання зазвичай звучить: "Яку платформу ви б обрали для нового проєкту і чому?" Відповідь залежить від існуючих інструментів, розміру команди, вимог відповідності та того, чи організація надає перевагу керованій інфраструктурі (GitHub/GitLab) чи повному контролю (Jenkins).

Джерела

• Actions steps can now be run in parallel (GitHub Changelog, червень 2026)
• GitLab 19.0 release notes (GitLab Docs, травень 2026)
• GitLab 19.2 release notes (GitLab Docs, липень 2026)
• Jenkins Changelog (Jenkins.io, серпень 2026)
• GitHub Actions 2026 Security Roadmap (GitHub Blog)

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

Ключові висновки для CI/CD Pipeline співбесід

• Паралельні кроки GitHub Actions (background, wait-all, parallel) випущені в червні 2026, дозволяючи паралельне виконання в межах одного завдання при спільному використанні runner, checkout та workspace
• GitLab 19.x представив нативний Secrets Manager (відкрита бета, травень 2026) та зробив політики запланованого виконання pipeline загальнодоступними (липень 2026), зменшуючи залежність від зовнішніх інструментів
• Jenkins 2.574+ виніс основні плагіни, включаючи JUnit та Mailer, з файлу WAR, вимагаючи явної інсталяції для екземплярів без доступу до центру оновлень
• Керування секретами є найчастіше тестованою темою безпеки на всіх трьох платформах: продемонструйте знання секретів з обмеженою областю, захищених змінних та стратегій ротації облікових даних
• Оптимізація pipeline через кешування, паралелізацію та умовне виконання застосовується універсально і сигналізує рекрутерам про практичний production-досвід
• Підготуйте щонайменше одну робочу конфігурацію pipeline для кожної платформи, зосереджуючись на реальних патернах, а не на toy-прикладах