Стратегія якості в пайплайні

У якому порядку мають виконуватись перевірки в CI і чому саме так?

Порядок майже завжди сталий — спершу lint, далі typecheck, тоді unit, потім integration і аж наприкінці e2e. Керує цим fail fast: що перевірка дешевша й швидша, то раніше вона в конвеєрі. Лінтер відповідає за частки секунди й обходиться без збірки; перевірка типів через tsc --noEmit знаходить розбіжності, не виконуючи коду; юніти малі та ізольовані; інтеграційні вимагають підняти БД або суміжний сервіс і тривають хвилини; наскрізні тягнуть застосунок у браузері й додають десятки хвилин та найбільше нестабільності. Виходить воронка: кожен ранній етап відкидає очевидний брак, поки важкий етап навіть не почався. Запускати браузерну матрицю, коли лінтер спіткнувся на неімпортованому символі, — це марно спалені хвилини. Фактично це той самий shift-left, згорнутий у межі одного конвеєра.

Що таке quality gate і як він фізично блокує merge?

Це формальний критерій pass/fail, без якого зміна не їде далі — ні в головну гілку, ні на середовище. По суті — та сама ідея entry/exit-критеріїв із тест-менеджменту, застосована до конвеєра: доступ у гілку відкривається лише після виконання списку умов. Механіка на GitHub — захист гілки (branch protection) разом із обовʼязковими перевірками (required status checks): поки перелічені джоби не позеленіють, кнопка злиття неактивна. У блокувальний перелік зазвичай входять лінт, перевірка типів, юніти, інтеграційні, smoke-частина наскрізних, успішна збірка, часом аудит залежностей (SCA), а поверх — обовʼязкове код-рев'ю та вимога актуальної гілки.

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

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

Які властивості відрізняють хороший quality gate від поганого?

Ознак чотири, і кожну має сенс перевіряти прямо на рев'ю CI-конфіга. Перша — швидкість: гейт має вкладатися в бюджет фідбеку на PR, це одиниці, ну максимум близько півтора десятка хвилин. Друга — детермінізм: однаковий код дає однаковий вердикт; плавучий гейт підриває довіру ще дужче, ніж повна його відсутність. Третя — інформативність: по червоному має бути зрозуміло, що конкретно впало і де лежить артефакт падіння, а не глухе «job failed». Четверта — відповідальність: у кожного червоного є той, хто його ремонтує; безхазяйний гейт розкладається. Провал хоч однієї ознаки поступово перетворює гейт на ритуал, який навчаються оминати.

Чому e2e зазвичай не ганяють на кожен PR?

Наскрізні тести водночас найповільніші, найтендітніші й найсильніше зав'язані на стан середовища. Якщо повісити блокувальний гейт на хиткий e2e-набір, довіра вмирає найшвидше: коли червоне у половині випадків означає флак, а не регресію, люди звикають перезапускати прогін або продавлювати злиття повз гейт. А гейт, який раз у раз оминають, захищає рівно нічого. Тому важкий набір відводять убік, а на PR тримають вузький і стабільний smoke основного сценарію — його блокувальність окупається, бо він короткий і майже не бреше.

Як розкласти прогони за трьома тригерами — PR, nightly, реліз?

Три конвеєрні розклади під три задачі. На кожен PR ганяють лінт, типи, юніти, інтеграційні/API, smoke основного шляху, збірку та SCA — це блокує злиття, бо мета тут швидкий і повторюваний вердикт як перепустка до merge. Уночі за розкладом cron ганяють увесь e2e, матрицю браузерів, повну регресію, візуальні й перф-смоук — merge це не блокує, зате в набору є господар; мета — виловити те, що для PR задовге або зашироке. Перед релізом — повна регресія на реліз-гілці, smoke на staging після викочування, скан безпеки і ручний exploratory-підпис; це блокує вже саме рішення про випуск. Основа розкладки — піраміда: чим нижче рівень тесту, тим частіше він біжить і тим більше блокує.

Як один і той самий код тестів обслуговує і smoke на PR, і повний набір у nightly?

Піднабір критичного шляху мітять тегом (скажімо, @smoke) і оформлюють окремим проєктом ранера — не копіюють у другу теку. У playwright.config.ts описують два проєкти: smoke фільтрує grep: /@smoke/, а full бере все, крім незавершеного, через grepInvert: /@wip/. Далі PR запускає --project=smoke, а нічний прогін — --project=full. Спільний код обслуговує обидва розклади, і правка будь-якого тесту сама доїжджає в них обох.

Чому зелений білд іноді нічого не гарантує?

«Зелено» мусить читатися як «перевірили й пройшло», але нерідко значить лише «не впало». Найтиповіше — тихо викинутий етап тестів: || true зʼїдає код виходу, continue-on-error: true не дає червоному завалити джоб, а порожній збіг тегів проганяє нуль тестів. Сюди ж покриття без асертів, коли тест проходить код, нічого не стверджуючи. На рев'ю конфіга ці конструкції варто вишукувати навмисне: зелений білд, під яким перевірки не бігали, шкідливіший за відверто червоний, бо сіє оманливу впевненість.

У чому небезпека coverage як гейта?

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

Яка зріла альтернатива вимозі «90% покриття на весь репозиторій»?

Замість тотального порога працюють дві речі. Diff-coverage (він же patch coverage) вимагає покриття лише на рядках, доданих у цьому PR: свіжа логіка їде разом із тестами, а давній непокритий код не валить кожне злиття; так уміють Codecov, Coveralls тощо. Храповик (ratchet) фіксує планку «не нижче нинішньої»: цифрі не обовʼязково дертися до магічного числа, зате падати їй не дозволено. І окреме табу — не чіпляти coverage-гейт на e2e, де відсоток бреше вже за самою природою. Тоді гейт лишається індикатором непокритої новизни, а не приводом накручувати відсоток.

Коли e2e пора виносити з блокувальних і як саме?

Тривожних сигналів три: багато флаку (тести падають, а на повторі без правок коду зеленіють), регулярні ручні перезапуски й продавлювання гейта, тривалість, що вилазить за бюджет фідбеку PR. Лікування — не «прибрати e2e», а рознести. На PR лишають короткий надійний smoke ключового флоу — вхід, оплата, головний сценарій — і його блокувальність тут доречна. Решту, важку й хитку, переносять у нічний прогін: merge він не блокує, але має власника, SLA на розбір і карантин для нестабільних. Захист нікуди не дівається — він просто перерозподіляється: швидкий надійний контур на PR і широкий контур під наглядом уночі.

Що означає застереження «неблокувальний ≠ нічий»?

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

Чому флакі-гейт гірший за відсутність гейта?

Уся цінність гейта — у передбачуваності. Хиткий гейт на тому самому коді видає то одне, то інше, тож команда перестає вірити червоному, машинально тисне перезапуск і врешті вчиться його оминати. Довіру до всього конвеєра це руйнує швидше, ніж якби гейта не було зовсім, — бо чесна відсутність принаймні нікого не заколисує. Отож хиткий блокувальний гейт треба або стабілізувати, або чесно перевести в неблокувальні з власником.

Які метрики здоровʼя пайплайна ти дивишся?

Конвеєр — теж продукт, і показників у нього дві сімʼї. Про сам конвеєр: green rate головної гілки (яку частку часу main зелений — постійно червоний main викриває, що гейт не тримає), час фідбеку PR у зрізах p50 і p95 (той самий «час до сигналу»: росте він — росте й бажання оминути конвеєр), time to green чи MTTR червоного main, частка флаку, як часто вручну перезапускають і продавлюють гейт (пряма міра недовіри), а ще тривалість сьюта та рахунок за ранери. Друга сімʼя — доставкові метрики DORA: як часто деплоять, lead time від коміту до прода, частка релізів зі збоєм, час на відновлення. DORA — про доставку й команду, не про тести, проте саме на неї зрештою лягає якість конвеєра; дивитися варто пучком, бо будь-яку метрику-ціль починають накручувати.

Приходиш на проєкт без CI-стратегії — з чого почнеш?

Переконлива відповідь — це послідовність думки, а не перелік тулзів. Стартують з інвентаризації: що за тести вже є, на яких рівнях, скільки тривають, наскільки флакують; яка модель гілкування; як часто викочують; де ризик найдорожчий (для магазину — кошик і оплата). Далі назначають бюджет фідбеку PR (умовно «до 10–12 хвилин») і під нього набивають етапи, паралелячи й кешуючи. Тоді гейти злиття: обовʼязкові перевірки — швидкі етапи, smoke, збірка, рев'ю, і кожне швидке та з власником. Важке — повну регресію, матрицю браузерів, візуальні — відводять у ніч із тріажером. Покриття кладуть на diff-coverage з храповиком, без «сто відсотків на репозиторій». Реліз-контур — повна регресія на реліз-гілці плюс smoke на staging. І під кінець — власність, метрики та ітерація, бо гейти не в граніті. Хто одразу сипле інструментами, програє тому, хто спершу питає про ризик і швидкість.

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

Кейс 1. Таблиця рішень: яку перевірку на який тригер

Питання не «які перевірки маємо», а «коли кожна бігає і що блокує». Розкладаємо той самий набір по трьох тригерах — і одразу видно, що коштовне стоїть за гейтом дешевого.

Читається просто: лівий стовпчик — швидкий детермінований контур під бюджет фідбеку PR; середній — усе задовге чи зашироке під наглядом уночі; правий — повнота перед виходом у прод. Один код тестів обслуговує PR і nightly через теги й окремі проєкти ранера:

// playwright.config.ts — один код, два розклади
export default defineConfig({
  projects: [
    { name: 'smoke', grep: /@smoke/ },     // критичний шлях, блокує merge
    { name: 'full',  grepInvert: /@wip/ }, // повний набір, у nightly
  ],
});

І два воркфлоу, де дорогий крок фізично стартує лише за зеленими дешевими:

# .github/workflows/pr.yml — блокувальний контур на кожен PR
on: pull_request
jobs:
  fast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test -- --coverage
  smoke:
    needs: fast                 # fail fast: браузер не піднімається, поки дешеве червоне
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright test --project=smoke

# .github/workflows/nightly.yml — важке, не блокує merge, але має власника
on:
  schedule:
    - cron: '0 2 * * *'
jobs:
  full-e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright test --project=full

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

• needs: fast — це і є fail fast у конфізі. Джоб smoke не стартує, поки lint/typecheck/unit не зелені; браузерну ферму не піднімають заради коду, що не компілюється.
• Required checks задають на боці репозиторію, не в YAML. У branch protection блокувальними роблять саме fast і smoke; nightly туди не потрапляє — інакше вранці ніхто не змерджить через нічний флак.
• --project=full у nightly має власника, а не «нехай висить». Cron без триажера перетворює нічний прогін на кладовище червоного.

Кейс 2. Флакуватий e2e-набір: розвести, не викинути

Ситуація з життя: 60 e2e блокують кожен PR, флак ~20%, розробники звикли тиснути re-run по два-три рази. «Зелене» вже нічого не гарантує, бо його домагаються повтором. Спокуса — зняти e2e з блокувальних цілком. Це помилка з іншого боку: тоді реальні регресії критичного шляху течуть у прод.

Правильний хід — розвести набір, а не рубати:

// playwright.config.ts — карантин нестабільних без втрати smoke
export default defineConfig({
  projects: [
    // блокує merge: лише критичний шлях і БЕЗ карантинних
    { name: 'smoke', grep: /@smoke/, grepInvert: /@flaky/ },
    // nightly: усе, крім незавершеного; @flaky тут під наглядом, неблокувально
    { name: 'full', grepInvert: /@wip/ },
  ],
});

// checkout.spec.ts
test('@smoke оплата картою проходить', async ({ page }) => { /* стабільний */ });

// нестабільний кейс — у карантині, поки стабілізують; не блокує PR
test('@flaky банер знижки зникає після скролу', async ({ page }) => { /* ... */ });

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

• На PR лишається малий стабільний smoke критичного шляху — логін, оплата, ключовий сценарій. Його блокувальність виправдана, бо він швидкий і рідко бреше.
• @flaky виходить із блокувального smoke, але лишається в full. Це карантин, а не смітник: кейс далі бігає вночі, є SLA на його стабілізацію й повернення.
• Пониження прозоре. У nightly має бути триажер із чек-листом «баг чи флак»; червоне без розбору гниє так само, як флакі-гейт. Неблокувальний не означає нічий.
• Не маскуй флак sleep-ами й ретраями наосліп. Ретрай ховає симптом; карантин + власник лікують причину.

Кейс 3. Coverage-гейт, який не бреше

Наївний гейт «90% рядків на весь репозиторій» ловиться на двох речах: покриття міряє виконання, а не перевірку, і рядки не дорівнюють гілкам. Ось функція, де один тест дає 100% line coverage і пропускає цілу гілку:

export function discount(price: number, isVip: boolean): number {
  let d = 0;
  if (isVip) {
    d = price * 0.2;   // ця гілка виконається лише за isVip === true
  }
  return price - d;
}

// тест, який дає високе покриття і майже нуль цінності
test('discount рахує знижку VIP', () => {
  discount(100, true);   // усі рядки виконано, але жодного expect — і гілка isVip=false не перевірена
});

Цей тест проходить кожен рядок функції, тож line coverage близький до 100% — але гілку isVip === false не перевірено (branch coverage ~50%), та ще й немає жодного асерту. Метрика зелена, захисту нуль.

Що ставити замість сакрального відсотка:

# codecov.yml — вимога до доданих рядків + храповик на весь проєкт
coverage:
  status:
    patch:            # diff-coverage: тільки нові рядки цього PR
      default:
        target: 80%
    project:          # храповик: не нижче поточного, без гонитви до 100%
      default:
        target: auto
        threshold: 0%

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

• patch (diff-coverage) вимагає тести до доданих рядків, а не до всього репо: нова логіка приходить покритою, старий непокритий код не блокує кожен PR.
• project: auto з threshold: 0% — це храповик. Покриття не мусить рости до магічного числа, але й не має падати; регрес видно одразу.
• Coverage-гейт не вішають на e2e — там цифра оманлива за побудовою: браузер проходить купу коду без жодного цільового асерту.
• Число — індикатор, а не бос. Низьке покриття — достовірний сигнал проблеми; високе саме по собі якості не гарантує, тому рев'ю самих тестів чесніше за будь-який поріг.

Порядок перевірок і fail fast

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

Quality gate і блокування merge

• Знаю, що quality gate — це умова pass/fail для злиття, прикладна форма entry/exit-критеріїв.
• Можу пояснити, що технічно merge блокують branch protection + required status checks.
• Назву чотири властивості хорошого гейта: швидкий, детермінований, дієвий, з власником.
• Розумію, чому флакі-гейт гірший за відсутність гейта, а гейт, який регулярно оверрайдять, — уже не гейт.

Розклад прогонів: PR / nightly / реліз

• Знаю мапінг піраміди на пайплайн: що нижчий рівень тестів, то частіше він бігає й то більше блокує.
• Розрізняю три розклади під три цілі: PR (блокує, швидкий фідбек), nightly (важке, з власником, не блокує merge), реліз (повний контур, рішення про реліз).
• Можу пояснити, як теги (@smoke) плюс окремі проєкти ранера обслуговують два розклади одним кодом.

Coverage як гейт

• Можу пояснити, чому покриття міряє виконання рядка, а не наявність асерту.
• Знаю різницю line coverage vs branch coverage і чому 100% рядків не дорівнює 100% гілок.
• Розумію закон Гудгарта в контексті coverage-порога: метрика-ціль накручується дешевими тестами.
• Знаю зрілу альтернативу: diff-coverage з храповиком замість «90% на весь репозиторій».

E2e і довіра до гейта

• Знаю сигнали, що e2e пора виносити з блокувальних: високий флак, часті ручні re-run/оверрайди, тривалість понад бюджет.
• Розумію правило «розвести, а не викинути»: стабільний smoke на PR + повний набір у nightly.
• Можу пояснити «неблокувальний ≠ нічий»: триажер, SLA на розбір, карантин для нестабільних.

Метрики й «зелений білд»

• Знаю ключові метрики пайплайна: green rate main, час фідбеку (p50/p95), MTTR червоного main, рівень флаку, частота оверрайдів.
• Можу відрізнити метрики пайплайна від DORA (частота деплоїв, lead time, change failure rate, час відновлення — рівень доставки, не тестів).
• Упізнаю «зелене, що нічого не перевірило»: || true, continue-on-error, порожній матч тегів.