CI/CD: інтеграція, доставка, розгортання

Що таке «інтеграційне пекло» і чому саме воно породило CI?

Це ситуація, коли команда довго не зливає код: кожен тижнями сидить у власній гілці, а наприкінці всі разом намагаються влити роботу в спільну гілку. Що довше гілки розходяться, то більше між ними накопичується несумісностей — і явних (той самий файл правили двоє), і тихих логічних (два окремо коректні шматки разом ламають фічу), і розбіжностей у залежностях. Складність такого злиття росте не лінійно, а різко, і вибухає рівно тоді, коли до релізу лишаються дні. Безперервна інтеграція (continuous integration, CI) перевертає логіку: якщо інтегруватися боляче — роби це часто, поки порція змін дрібна, і тоді конфлікт видно й лагодиться за хвилини. Тобто CI народилася не як технологія, а як відповідь на конкретний організаційний біль.

CI — це інструмент чи практика? Чому це питання не чіпляння до слів?

CI — передусім практика, дисципліна команди, а не сервер, який ти встановив. Можна підняти GitHub Actions чи Jenkins і не мати ніякого CI, якщо всі далі сидять по гілках тижнями й зливаються раз на спринт. І навпаки: суть CI — часте злиття в спільну магістраль плюс автоматична перевірка кожного злиття, а інструмент лише автоматизує те, що команда й так вирішила робити. На співбесіді ця відповідь одразу відрізняє того, хто розуміє механізм, від того, хто завчив назви систем. Слабка відповідь звучить як «CI — це коли стоїть Jenkins, що ганяє тести».

Розкажи своїми словами, що таке безперервна інтеграція.

Два стовпи: розробники часто (щодня чи кілька разів на день) зливають дрібні порції змін у спільну гілку, і на кожне таке злиття автоматика збирає проєкт та проганяє тести. Мета — тримати спільну гілку в робочому стані постійно, а не «доводити її до пуття» перед релізом. Сильна відповідь додає причину — «інтеграційне пекло» рідкісного злиття великих гілок — і наголошує, що це практика, а не просто «машина, яка запускає тести». Ще один маркер зрілості: згадка про trunk-based development як спосіб життя, що робить часте злиття можливим. Слабка відповідь зупиняється на «сервер збирає код».

Які звички команди роблять CI справді робочим?

Перша — часті дрібні коміти в спільну гілку замість великої фічі раз на два тижні. Друга — автоматична перевірка (білд плюс тести) на кожен коміт, яку запускає машина, а не людина за настроєм. Третя, і найнедооціненіша — «зелена магістраль понад усе»: якщо перевірка червона, спільна гілка вважається зламаною, і команда лагодить її раніше, ніж додає нове. Це той самий принцип, що на реальному складальному конвеєрі — не пускай далі деталь із дефектом. Без третьої звички CI перетворюється на декорацію: червоне накопичується, ніхто його не чинить, гейт втрачає сенс.

Опиши механіку одного прогону CI від пуша до статусу.

Розробник робить git push або відкриває Pull Request — CI-сервер помічає цю подію. Він бере свіжий код, у чистому відтворюваному середовищі збирає проєкт, проганяє тести й повертає статус: зелено або червоно. Статус видно прямо в Pull Request — червоний чек блокує злиття, зелений дозволяє. Головна цінність цієї петлі — регресію ловить машина за хвилини після коміту, а не тестувальник за тиждень перед релізом, і «в мене локально працювало» перестає бути аргументом, бо збірка йде в однаковому для всіх середовищі. Історія перевірок прив'язана до комітів, тож видно, який саме коміт зробив магістраль червоною.

Чим CI відрізняється від CD?

Це класична пастка через подвійне «CD»: обидва Continuous Delivery і Continuous Deployment скорочуються однаково, тому сильна відповідь одразу їх розводить. CI відповідає за відрізок від коміту до готового артефакта: інтегрувати, зібрати, протестувати — на виході перевірена збірка. Обидва CD — про те, що з цим артефактом робити далі: доводити його до релізу. Continuous Delivery тримає кожну зелену збірку готовою до релізу «в один клік», а рішення котити на prod ухвалює людина. Continuous Deployment прибирає й цей клік: кожна збірка, що пройшла всі перевірки, їде на prod автоматично. Водорозділ між двома CD — наявність ручного апруву перед prod.

У чому конкретно різниця між Continuous Delivery і Continuous Deployment?

Різниця рівно в одному: чи є людина в петлі релізу перед продакшеном. При Continuous Delivery пайплайн автоматично доводить збірку до стану «готово релізити» — прогнано через усі стадії, розгорнуто на staging, — але саму кнопку «на prod» тисне людина у свідомий момент. При Continuous Deployment кнопки немає: пройшли всі гейти — збірка поїхала на prod сама. Друге вимагає значно зрілішого автоматизованого контролю якості, бо ніхто не дивиться на збірку перед prod очима — весь захист переноситься в перевірки пайплайна, спостережуваність і швидкий rollback. Тому Continuous Deployment без сильної автоматизації якості — це не швидкість, а рулетка.

Чи можна мати Continuous Deployment без Continuous Delivery?

Ні — Continuous Delivery це обов'язкова передумова, а не навпаки. Щоб релізити на prod автоматично без людини, спершу треба вміти стабільно доводити кожну збірку до стану «готова до релізу»: пройдена через усі стадії, розгорнута на staging, перевірена автоматичними гейтами. Continuous Deployment лише знімає останній ручний клік із уже налагодженого Continuous Delivery. Спроба «зразу автоматичний prod» без цієї бази означає, що збірки їдуть у прод, не будучи гарантовано готовими — а це прямий шлях до інцидентів. Тому послідовність завжди CI → Delivery → Deployment, і перескочити середню ланку не вийде.

Що таке пайплайн і чому його називають конвеєром якості?

Пайплайн (pipeline) — це автоматизована послідовність стадій, які код проходить від коміту до потенційного продакшену. Правильна ментальна модель — конвеєр контролю якості: на кожній станції стоїть перевірка, і деталь їде далі, лише якщо станцію пройдено. Не пройшов lint — далі не поїхав; впав unit-тест — до e2e справа взагалі не дійшла. Тобто це не «купа скриптів, які запускаються», а впорядкована черга гейтів, кожен з яких — фільтр, що не пускає дефект далі по трубі. Для AQA це ще й середовище, у якому живуть автотести: там вони запускаються на кожен коміт і там стають блокувальним гейтом.

У якому порядку йдуть стадії пайплайна і чому саме так?

Типовий порядок — lint і перевірка типів, потім unit-тести, потім integration/API, і аж наприкінці e2e. Принцип за цим — fail fast: спершу найшвидші й найдешевші перевірки, потім повільні й дорогі. Логіка суто економічна — немає сенсу тримати агента пів години на e2e, якщо код не проходить навіть перевірку типів; цю помилку треба показати автору за секунди, а не за десятки хвилин. Порядок прямо лягає на піраміду тестування: широка дешева основа знизу, вузький дорогий верх. Сильна відповідь на співбесіді називає не лише послідовність, а й це «чому»: раннє падіння економить час і гроші та дає автору швидкий фідбек.

Чим білд відрізняється від артефакта?

Білд (build) — це дія, процес перетворення вихідного коду в форму, придатну до запуску: для компільованих мов це компіляція, для веб-стека — встановити залежності, перевірити типи, зібрати й мінімізувати бандл, проставити хеші в назви файлів. Артефакт (artifact) — це результат білда: незмінний пакет, готовий до розгортання (зібраний бандл, Docker-образ, .jar, .zip, набір статичних файлів). Ключова властивість артефакта — незмінність. Звідси й межа з деплоєм: білд виробляє артефакт, а деплой ставить готовий артефакт у середовище — це різні дії. Плутати «білд» і «деплой» як один крок — типова помилка новачка.

Що означає принцип build once, deploy many і чому він критичний саме для QA?

Він означає «зібрати один раз, розгорнути багато разів»: артефакт збирають раз, а далі той самий незмінний артефакт просувають середовищами staging → prod, не перезбираючи окремо під кожне. Для QA це фундамент довіри до тестування: на staging ти перевіряєш той самий байт-у-байт артефакт, що поїде в prod, тож твоє тестування staging реально щось гарантує. Якби під prod робили нову збірку, у прод могла б заїхати інша збірка, і перевірка staging нічого не варта. Друга перевага — трасування: артефакт прив'язаний до конкретного коміту й версії, тож зловивши баг у prod, ти знаєш точну збірку й точний коміт. Практичний висновок: різницю поведінки між середовищами треба шукати не в коді (він той самий), а в конфігурації та даних.

Що таке shift-left і як CI з ним пов'язаний?

Зсув уліво (shift-left) — це принцип пересувати перевірки якості якомога раніше на часовій осі проєкту, ближче до написання коду. Основа — крива вартості дефекту: чим пізніше знайдено баг, тим дорожче його виправити; баг на коміті коштує кількох хвилин, той самий баг у проді — інциденту й hotfix-у. CI — головний технічний механізм shift-left: він переносить прогін тестів із окремої «фази тестування наприкінці» на кожен коміт, і тестування вплітається в саму розробку. Сильна відповідь пов'язує термін саме з вартістю дефекту й з CI як інструментом раннього виявлення, а не просто перекладає слово «зсув». Слабка — «shift-left це коли тестуємо раніше», без пояснення механізму й вигоди.

Чому швидкість і стабільність пайплайна — це умова, а не зручність?

Уся цінність CI тримається на швидкості петлі «закомітив → дізнався результат». Якщо пайплайн іде дві години або миготить без причини, петля зворотного зв'язку розривається: люди перестають чекати результату, накопичують зміни великими пачками, зливаються рідше — і команда повертається в те саме інтеграційне пекло, тільки тепер із логотипом CI-системи згори. Тобто повільний чи нестабільний пайплайн не просто дратує — він знищує сам сенс безперервної інтеграції. Тому швидкість (fail-fast порядок стадій) і стабільність (боротьба з flaky) — це не косметика, а умова, за якої CI взагалі працює. Для AQA це прямий обов'язок: тримати сюїту швидкою й надійною.

Чому один flaky-тест здатний знецінити весь пайплайн?

Flaky-тест падає «через раз» без зміни коду, і саме ця непередбачуваність отруює гейт. Коли пайплайн червоніє випадково, команда поступово перестає довіряти червоному кольору й починає його ігнорувати — ретраїть джобу, не читаючи причину. А щойно червоне стало «нормальним», гейт перестав бути гейтом: наступного разу за випадковим червоним сховається справжня регресія, і її пропустять. Тобто шкода не в самому падінні, а в підриві довіри до сигналу. Тому тримати сюїту вартою довіри — пряма робота QA: один хронічно нестабільний тест дорожчий, ніж відсутній.

Чому «зелений пайплайн» не завжди означає «можна релізити»?

Бо зелене означає лише «перевірки, які ми написали, пройшли» — не «продукт справний». Тонка сюїта з дірявим покриттям чи набір flaky-тестів дадуть зелене на функціоналі, який насправді зламаний, просто його ніхто не перевіряє. Зелений колір рівно настільки цінний, наскільки чесні й повні перевірки за ним. Тому за зеленим гейтом мусить стояти продумана стратегія якості: що саме блокує злиття, яке покриття вважається достатнім, які ризики свідомо лишили поза автоматикою. Сприймати зелене як залізну гарантію релізу — типова помилка, яка присипляє пильність.

Чому звичка «впав пайплайн — просто зроблю ретрай» небезпечна?

Бо ретрай не лагодить причину, а маскує її. За випадковим падінням стоїть або flaky-тест, або реальна регресія, що спрацювала на конкретних таймінгах — і «ретраїв, позеленіло» означає не «полагоджено», а «відкладено до наступного разу». Гірше те, що звичка ретраїти вбиває довіру до гейта: команда привчається не читати червоне, а клікати «retry», і одного дня за цим retry проскочить справжній баг. Правильна реакція на червоне — розібратися, чому впало, і завести це у три категорії: баг продукту, баг тесту чи інфраструктура. Тріаж падінь — щоденна робота AQA, і підміняти його кнопкою ретраю дорого коштує.

Де місце QA у зрілій CI/CD-культурі?

Слабка відповідь — «QA тестує наприкінці». Сильна — якість не пришивають наприкінці, її вбудовують у пайплайн, а QA стає стюардом цієї автоматизованої страхувальної сітки. Конкретно QA пише й володіє автоперевірками в пайплайні, визначає гейти якості (що блокує злиття, а що лише інформує; де e2e блокувальний, а де винесений у nightly), тріажить падіння (продукт / тест / інфраструктура), тримає сюїту вартою довіри й рев'ює тестовий код у Pull Request нарівні з продуктовим. У цій моделі якість — відповідальність усієї команди, але саме QA проєктує й доглядає механізм, який цю якість стереже. Це перехід від «тестувальника, що клікає» до інженера, що володіє захисною сіткою релізу: девопс володіє інфраструктурою, QA — вмістом перевірок.

Три ситуації, у яких CI/CD перестає бути теорією й стає щоденною роботою AQA: тріаж червоного пайплайна за таблицею причин, читання fail-fast пайплайна в GitHub Actions і рішення, який гейт куди поставити, та розбір «на staging працювало, на prod ні» через призму build once, deploy many. Скрізь — що дивитися й чому.

Кейс 1. Червоний пайплайн: тріаж за три категорії

Пайплайн упав на PR, і перша реакція новачка — клікнути «Re-run jobs». Це найгірше, що можна зробити: ретрай не каже, що сталося, а лише відкладає діагноз. Червоне падіння завжди розкладають у три категорії — баг продукту, баг тесту, інфраструктура — бо лікуються вони по-різному, і плутати їх дорого.

Що дивитися й чому:

• Стабільність відтворення — головний розділювач. Падіння, що чесно повторюється на тому самому коміті, — це або регресія продукту, або зламаний асерт. Падіння, що «через раз», — майже завжди flaky-тест чи гонка, і його не можна «полагодити ретраєм»: позеленіло — значить, відклали, а не полагодили.
• 5xx від застосунку в момент прогону — окремий діагноз. Масові 502/503 одразу після деплою частіше означають, що середовище ще прогрівається, ніж баг продукту; спершу переконайся, що застосунок піднявся, а вже потім заводь дефект.
• Локально зелено, у CI червоно — не привід звинувачувати CI. Прогін у CI йде в headless-браузері, з іншими ресурсами й таймінгами, тож нестабільність вилазить саме там. Це не «поламаний CI», а тест, який спирався на удачу локальної машини.
• Тріаж — це відповідальність QA, а не девопса. Девопс володіє інфраструктурою, але рішення «це баг продукту / тесту / середовища» ухвалює той, хто розуміє вміст перевірок.

Кейс 2. Fail-fast пайплайн у GitHub Actions і місце e2e-гейта

Порядок стадій у пайплайні — не косметика, а економіка: дешеве й швидке має падати першим, поки автор ще за клавіатурою. У GitHub Actions цей порядок задають залежності needs — джоб не стартує, поки не позеленів попередній.

name: ci
on: [pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint && npm run typecheck   # секунди

  unit:
    needs: lint            # не запуститься, поки lint червоний
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run test:unit                    # секунди-хвилини

  e2e:
    needs: unit            # найдорожча стадія — остання
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright test --project=chromium   # десятки хвилин

Ту саму e2e-сюїту можна не тримати блокувальною на кожному PR, а винести важку її частину в nightly — окремий запуск за розкладом:

name: nightly-e2e
on:
  schedule:
    - cron: '0 2 * * *'   # щоночі о 02:00 — повний регрес, усі браузери
jobs:
  full-e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright test   # усі проєкти, довгий хвіст сценаріїв

Що дивитися й чому:

• needs — це і є fail-fast. Якщо lint червоний, unit і e2e навіть не стартують: агент не витрачає пів години на e2e для коду, що не проходить перевірку типів. Помилку автор бачить за секунди, а не наприкінці.
• Порядок повторює піраміду тестування. Багато дешевих unit знизу, кілька дорогих e2e зверху — це не випадковість, а той самий принцип «широка дешева основа, вузький дорогий верх», перенесений у пайплайн.
• Рішення «блокувати чи винести в nightly» — стратегія якості, і його ухвалює QA. Швидкий смоук-e2e тримають гейтом на PR; повний регрес по всіх браузерах ганяють уночі, щоб не гальмувати кожен коміт. Це компроміс між швидкістю фідбека й повнотою покриття.
• Зелений цієї сюїти каже рівно те, що написано. Якщо на PR блокує лише смоук-набір, «зелено» не означає «повний регрес пройдено» — воно означає «пройшли ті перевірки, що на гейті». Плутати одне з іншим — присипляти пильність.

Кейс 3. «На staging працювало, на prod зламалось»: build once, deploy many на практиці

Фіча відпрацювала на staging, а в prod одразу після релізу — помилка. Перша думка новачка — «код у prod інший». Якщо процес побудований правильно, це майже завжди хибний слід: артефакт зібрали раз і той самий незмінний просунули staging → prod, тож код там байт-у-байт однаковий. Отже, шукати треба не в коді, а в конфігурації та даних.

Щоб зняти саме питання «а чи справді там той самий артефакт», перед прогоном сюїти корисно мати оракул версії — застосунок віддає свою збірку, а тест звіряє її з очікуваною:

import { test, expect } from '@playwright/test';

test('на середовищі крутиться очікувана збірка', async ({ request }) => {
  // застосунок віддає свій build/commit, наприклад, у /healthz або /version
  const res = await request.get(`${process.env.BASE_URL}/version`);
  expect(res.status()).toBe(200);

  const { commit } = await res.json();
  // очікувану версію передаємо з CI (SHA артефакта, що деплоївся)
  expect(commit, 'на середовищі стара збірка — деплой не доїхав').toBe(process.env.EXPECTED_SHA);
});

Якщо версія збіглася, а поведінка все одно різна — розбір іде за таблицею відмінностей середовищ:

Конкурентність (concurrency) в останньому рядку — це скільки запитів застосунок обслуговує водночас; не плутай її з паралельністю, тобто одночасним прогоном незалежних тестів.

Що дивитися й чому:

• Незмінність артефакта — це те, що робить тестування staging осмисленим. Ти перевіряєш той самий байт, що поїде в prod; якби під prod робили нову збірку, перевірка staging нічого б не гарантувала.
• Оракул версії відсікає найдешевшу гіпотезу першою. Половина «загадкових» різниць між середовищами — це банально не доїхав деплой: у prod ще стара збірка. Звіривши SHA, ти або підтверджуєш це за секунди, або чесно виключаєш і йдеш далі.
• Трасування до коміту економить години. Артефакт прив'язаний до конкретної версії, тож зловивши баг у prod, ти знаєш точну збірку й точний коміт, звідки вона зросла, — не треба гадати «а що ж там задеплоєно».
• Різницю шукай у конфізі й даних, а не в коді. Це прямий наслідок build once, deploy many: код той самий за побудовою, тож усе, що відрізняється, живе в оточенні середовища.

Інтеграційне пекло і суть CI

• Можу пояснити «інтеграційне пекло»: що довше гілки розходяться, то різкіше (нелінійно) росте складність злиття, і вибух припадає на дедлайн.
• Знаю головну тезу: CI — це практика й дисципліна команди, а не інструмент; Jenkins сам по собі ще не CI.
• Можу назвати три звички робочого CI: часті дрібні коміти в спільну гілку, автоперевірка на кожен коміт, «зелена магістраль понад усе».
• Розумію правило «не пускай далі деталь із дефектом»: червона магістраль — стоп-сигнал, її лагодять раніше, ніж додають нове.

Механіка і роль автотестів

• Можу описати петлю: push/PR → CI бере свіжий код → чисте середовище → білд → тести → статус green/red у Pull Request.
• Розумію, чому «в мене локально працювало» перестає бути аргументом: збірка йде у відтворюваному, однаковому для всіх середовищі.
• Можу пояснити, чому один flaky-тест руйнує весь сенс CI: команда перестає довіряти червоному й починає його ігнорувати.

CI vs Delivery vs Deployment

• Можу розмежувати відрізки пайплайна: CI — від коміту до артефакта; Delivery — до «готово релізити одним кліком»; Deployment — до автоматичного prod.
• Знаю водорозділ двох CD: наявність ручного апруву перед prod (Delivery — людина тисне кнопку; Deployment — кнопки немає).
• Розумію, що Continuous Delivery — обов'язкова передумова Continuous Deployment, але не навпаки.

Пайплайн як конвеєр якості

• Розумію пайплайн як конвеєр контролю якості: кожна стадія — гейт, деталь їде далі лише пройшовши станцію.
• Знаю fail-fast порядок стадій: lint/типи → unit → integration/API → e2e, і можу пояснити чому (дешеве й швидке раніше).

Білд і артефакт

• Можу розвести білд (дія, процес збірки) і артефакт (результат: незмінний пакет, готовий до розгортання).
• Знаю ключову властивість артефакта — незмінність, і межу з деплоєм: білд виробляє артефакт, деплой ставить його в середовище.
• Розумію принцип build once, deploy many: один артефакт просувають середовищами, а не перезбирають під кожне.
• Можу пояснити, чому це критично для QA: на staging тестую той самий байт-у-байт артефакт, що поїде в prod.

Shift-left і роль QA

• Можу пояснити shift-left через криву вартості дефекту: чим пізніше знайдено баг, тим дорожче виправити.
• Розумію, що CI — головний технічний механізм shift-left: тести переносяться з «фази наприкінці» на кожен коміт.
• Можу назвати обов'язки QA у CI/CD: володіння автоперевірками, визначення гейтів, тріаж падінь, здоров'я сюїти, рев'ю тестового коду в PR.
• Розумію тезу «зелений пайплайн ≠ можна релізити»: зелене означає лише, що написані перевірки пройшли, не що продукт справний.