Середовища, деплой і релізи

Що таке середовище і навіщо тримати окремі dev, staging і prod?

Середовище (environment) — це самостійний екземпляр застосунку зі своєю інфраструктурою, базою даних і конфігурацією; код усюди однаковий, а дані, інтеграції й налаштування різні. Драбина потрібна, бо кожна сходинка ловить свій клас проблем: на dev розробник перевіряє сирий код і не боїться його зламати, staging — останній гейт, максимально схожий на бойовий, а prod має бути завжди зеленим для реальних користувачів. Часто драбина довша — окремий QA-стенд, UAT для замовника, sandbox для інтеграцій, — але напрямок один: код рухається знизу вгору. Для QA це означає, що баг, спійманий на staging, коштує на порядки дешевше за той самий баг на prod. Плутати середовища небезпечно: перевірка, що реально знімає гроші чи розсилає пошту справжнім користувачам, перетворюється на аварію, а не на тест.

Що таке паритет середовищ і чому «на staging працює, а на prod падає»?

Паритет середовищ (environment parity) — це ступінь, до якого staging збігається з prod у всьому, крім даних і масштабу. Ідеал недосяжний на практиці: різняться версії залежностей і бази, конфіги, набір увімкнених флагів, присутність кешу чи CDN. Саме ці розбіжності породжують найпідступніший клас багів, коли на передрелізному стенді все зелено, а на бойовому щось відвалюється. Тому «пройшло на staging» — не гарантія, а лише сильний сигнал; частина перевірок усе одно лишається на prod. Для QA практичний висновок: коли баг відтворюється тільки на одному середовищі, перше питання — чим це середовище відрізняється конфігурацією, а не «де в коді помилка».

Яка різниця між деплоєм і релізом?

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

Що таке post-deploy smoke і чим він відрізняється від регресії на PR?

Post-deploy smoke (перевірка розгортання) — це короткий набір перевірок критичного шляху одразу після деплою, який відповідає на одне питання: релізу можна довіряти чи негайно відкочувати. Різниця з регресією на PR — в об'єкті й адресаті: регресія перевіряє код до злиття, ганяючись проти тестового білда, а smoke перевіряє конкретне розгортання на конкретному середовищі — уже піднятий застосунок з його реальною конфігурацією, базою й мережею. Деплой сам по собі нічого не гарантує: він лише скопіював артефакт, а чи піднявся процес, чи доступна БД, чи не забули змінну — це окрема перевірка. Smoke має бути швидким (хвилини) і стабільним, бо блокує промоушен релізу. У зрілому пайплайні його провал автоматично тригерить відкат.

Що покласти в мінімальний smoke після деплою?

Мінімум — це перевірка, що інфраструктура жива і критичний шлях працює, а не повне покриття функціоналу. Типовий набір: health-ендпоінт відповідає 200, головна сторінка рендериться, логін проходить, один-два наскрізні критичні сценарії відпрацьовують (для маркетплейсу — «пошук → картка товару → додати в кошик»). Ганяти smoke треба проти реального URL середовища, а не проти білда: тільки так перевіряється саме це розгортання з його конфігурацією. Важлива стриманість: смок роздувати не можна, бо він блокує реліз — усе інше йде в повну регресію. Якщо смок падає, промоутити не можна навіть за «зелену» регресію на PR, бо це різні перевірки.

Чим відрізняються rolling, blue-green і canary, і коли що обрати?

Три стратегії торгують ризиком за інфраструктуру. Rolling оновлює інстанси по черзі — дешево, подвійна інфраструктура не потрібна, але під час деплою дві версії обслуговують трафік одночасно, а відкат повільний. Blue-green тримає два ідентичні середовища й перемикає весь трафік із поточного на нове однією операцією балансувальника — головний плюс миттєвий відкат назад, ціна — подвійна інфраструктура. Canary віддає новій версії маленьку частку трафіку (умовно 1–5%), стежить за метриками й нарощує до 100% лише за здорових показників — найкращий контроль ризику, але вимагає зрілої спостережуваності. Сильна відповідь не переказує означення, а прив'язує вибір до ризику й наявної інфраструктури: критичний сервіс із жорсткою вимогою до відкату — blue-green чи canary; проста стабільна система з обмеженими ресурсами — rolling.

Чому rolling вимагає зворотної сумісності?

Бо під час поступової заміни інстансів стара й нова версії якийсь час працюють пліч-о-пліч і обслуговують той самий трафік. Один запит користувача може потрапити на старий інстанс, наступний — на новий, тож новий код мусить розуміти старі дані й запити, а API — старих клієнтів. Класична пастка тут — несумісна міграція БД: якщо новий реліз перейменував чи видалив колонку, старі інстанси, які ще живі, впадуть на зміненій схемі. Безпечний патерн — expand-contract: спершу додати нове, не ламаючи старого, а прибрати старе лише після повного деплою. Та сама логіка стосується canary, де версії теж співіснують; blue-green від цього частково рятує, але спільна база все одно вимагає обережності.

Як працює canary і чому він дає найкращий контроль ризику?

Canary (канарковий реліз, назва — від канарки в шахті) спершу пускає нову версію лише на маленьку частку трафіку, а решта користувачів лишається на старій. Метрики нової версії — частота помилок, латентність, бізнес-показники — порівнюють зі старою в реальному часі. Якщо показники здорові, частку поступово нарощують (умовно 5 → 25 → 50 → 100%); якщо видно деградацію, відкочують, зачепивши мінімум людей. Контроль ризику найкращий саме тому, що проблему видно на крихітній вибірці до масового деплою, і рішення про просування чи відкат приймається за живими даними. Але без метрик і логів canary перетворюється на повільніший спосіб зламати прод — тому роль QA тут почасти в тому, щоб заздалегідь задати пороги (наприклад, error rate і p95-латентність), за якими деплой зупиняється.

Що таке feature flag і як він розриває зв'язок між деплоєм і релізом?

Feature flag (фіча-флаг, feature toggle) — умовний перемикач у коді, який дозволяє вмикати й вимикати шматок функціональності, не викочуючи новий деплой. Головна ідея: код фічі може бути вже на проді, але вимкнений флагом, тож деплой (код на середовищі) і реліз (фіча доступна) стають окремими подіями, і відкриття фічі — це зміна конфігурації. Практична цінність для команди велика: kill switch дозволяє вимкнути зламану фічу за секунди без rollback і білда — це найшвидший відкат, що існує; поступове відкриття по когортах працює як canary на рівні фічі; а тестові акаунти можуть бачити фічу на живому середовищі, поки для решти вона закрита. Тому «задеплоїли» і «зарелізили» — не одне й те саме, і флаг робить цей розрив явним і керованим.

Як тестувати feature flag і чому важливо задавати його стан явно?

Залежно від стану флага один і той самий білд дає різну поведінку, тому в setup тесту цей стан виставляють явно — через API конфігурації, cookie чи заголовок оверрайду, — а не покладаються на дефолт середовища. Інакше тест «іноді зелений»: це той самий флак, тільки причина не в синхронізації, а в конфігурації. Тестувати треба обидві гілки, поки флаг живий: і on, і off присутні в проді одночасно, тож стара й нова поведінка обидві мають бути перевірені. Щодо кількості конфігурацій: N незалежних флагів дають 2^N комбінацій, тож увесь декартів добуток не перекриєш — покривай релевантні комбінації за тією ж логікою, що й попарне тестування. Слабка відповідь звучить як «поклацаю з увімкненим флагом» і пропускає і другу гілку, і явне задання стану.

Що таке flag debt і чому це проблема для тестування?

Flag debt — це мертві фіча-флаги, які лишилися в коді після того, як фіча вже розкотилася на 100% користувачів. Флаг і його else-гілка живуть роками, хоча ніколи більше не вимикаються, і це не косметична проблема. По-перше, кожен живий флаг формально подвоює простір конфігурацій (2^N), а отже й обсяг того, що теоретично треба перевіряти. По-друге, мертва гілка коду вводить в оману: незрозуміло, чи вона ще потрібна, і чи покривати її тестами. Прибирання відпрацьованих флагів — частина інженерної гігієни, і QA має право наполягати на ньому, коли бачить, що флаг давно у стабільному стані. Інакше комбінаторний вибух росте на порожньому місці.

За що відповідає QA в A/B-експерименті і що таке sticky assignment?

A/B-тест перевіряє продуктову гіпотезу, а не якість коду: користувачів випадково ділять на варіанти — контрольний і один чи кілька експериментальних, — і порівнюють цільову метрику. QA тут гарант валідності експерименту, а не «людина, що клацнула обидва варіанти». Ключова річ — sticky-призначення (sticky assignment): одиниця рандомізації (найчастіше користувач або сесія) має стабільно бачити той самий варіант протягом усього експерименту. Якщо варіант мерехтить між візитами, і досвід зламаний, і дані брудні. Перевіряють три речі: стабільність призначення, відповідність реального розподілу заявленому (обіцяні 50/50 мають на ділі дати приблизно рівні групи) і коректність трекінгу подій — кожна рівно раз. Різке відхилення фактичного розподілу від очікуваного — окремий сигнал тривоги.

Що таке sample ratio mismatch і про що він сигналить?

Sample ratio mismatch (SRM) — це коли фактичне співвідношення користувачів між варіантами A/B помітно відхиляється від заявленого: наприклад, замість очікуваних 50/50 виходить 54/46. Це не дрібниця, а червоний прапор: він означає, що з експериментом щось технічно не так — баг у сплітері, який ділить трафік нерівномірно, або фільтрація ботів чи внутрішнього трафіку зачепила лише один варіант. Головний наслідок: за наявності SRM результатам експерименту довіряти не можна, навіть якщо цільова метрика показує «красивий» ефект, бо самі групи вже незіставні. Тому перевірка спліту — базова гігієна перед тим, як узагалі дивитися на конверсію. Для QA це прямий обов'язок: зловити SRM до того, як команда почне святкувати неіснуючий приріст.

Як відкотити реліз, який зачепив схему БД?

Це класичний senior-фільтр, бо тут видно, хто реально релізив. Код відкотити легко, дані — ні: якщо реліз накотив несумісну міграцію (перейменував колонку, видалив поле), простий відкат коду впаде на вже зміненій схемі. Тому міграції проєктують зворотно сумісними за патерном expand-contract: спершу тільки додаємо нове, не ламаючи старого (expand), код обох версій якийсь час працює з розширеною схемою, і лише після повного деплою прибираємо старе (contract). За такого підходу код можна відкотити, не чіпаючи БД. Спосіб відкату залежить і від стратегії деплою: blue-green — перемкнути балансувальник назад, canary чи флаг — вимкнути за секунди, rolling — викотити попередню версію повільним механізмом; завжди лишається redeploy збереженого артефакту. Головне — щоб план відкату існував і був відрепетируваний заздалегідь, бо «відкотимося, якщо що» без перевіреної процедури в момент інциденту не спрацьовує.

Що таке SemVer і що означають його частини?

Семантичне версіонування (semantic versioning, SemVer) — домовленість, за якою кожна цифра версії щось означає, а не просто інкрементується; версія складається з трьох чисел MAJOR.MINOR.PATCH, скажімо 2.4.1. MAJOR-бамп означає несумісні зміни (breaking changes), які зламають наявних споживачів: 1.x.x → 2.0.0. MINOR — нова можливість, що не ламає сумісності: 2.4.x → 2.5.0. PATCH — лагодження без зміни контракту: 2.4.1 → 2.4.2. Є ще pre-release і build-мітки на кшталт 2.5.0-rc.1, а версії 0.y.z — рання фаза, де ламати можна будь-коли. Для QA версія — це очікування: MAJOR у залежності означає планувати регрес на breaking changes, PATCH — очікувати незмінний контракт. Чесне застереження: SemVer поважають не всюди — багато продуктів релізяться за датою (CalVer, 2026.07), номером білда чи git-хешем, тож це конвенція для версійованих контрактів, а не універсальний закон.

Поясни різницю між ^1.2.0 і ~1.2.0 у package.json.

Обидва записи — це діапазони версій, які дозволяють npm install підтягнути не рівно 1.2.0, а сумісну новішу. Карет ^1.2.0 дозволяє будь-яке оновлення, що не міняє MAJOR, тобто MINOR і PATCH: підійде 1.3.0 чи 1.2.5, але не 2.0.0. Тильда ~1.2.0 вужча — дозволяє лише PATCH у межах указаного MINOR: 1.2.5 так, а 1.3.0 уже ні. Практичний наслідок, важливий для QA: через ці діапазони збірка може «поплисти» без жодних змін у твоєму коді — учора підтягнулась одна версія залежності, сьогодні інша, і звідси «нічого не міняв, а зламалось». Саме тому існує lock-файл, який фіксує точні версії; без нього діапазони роблять білд невідтворюваним. Розуміння цього прямо годує діагностику раптових падінь після чистого npm install.

Що таке testing in production і які запобіжники обов'язкові?

Testing in production — це свідома, контрольована перевірка частини сценаріїв на бойовому середовищі, бо деякі проблеми інакше не спіймати: реальний обсяг і форму даних, справжній патерн трафіку, поведінку сторонніх інтеграцій. Staging завжди трохи бреше, тож зрілі команди доповнюють (не заміняють) ним тестування до прода. Техніки: canary й фіча-флаги (нова поведінка лише для мікрочастки чи тестових акаунтів), synthetic monitoring (автотести критичного шляху проти prod за розкладом з алертами — постійне продовження smoke), shadow traffic (копію реальних запитів шлють на нову версію, а відповіді відкидають), A/B і RUM. Без запобіжників це не тестування, а інцидент: не псувати реальні дані (тестові акаунти, sandbox для платежів і пошти), обмежувати радіус ураження (флаги, canary) і мати спостережуваність плюс швидкий kill switch, щоб бачити наслідки й вимкнути за секунди. Головна теза: воно виявляє те, чого не відтворити на staging, проте не відміняє ані smoke, ані регресію на нижчих середовищах.

Три кейси, де тема «середовища й релізи» перетворюється на конкретні рішення QA: як обрати стратегію розгортання під ризик і не проґавити пастку зі змішаними версіями, як написати post-deploy smoke проти реального середовища й тест фіча-флага, що перевіряє обидві гілки, і як перевірити валідність A/B-експерименту, перш ніж вірити його цифрам. Скрізь — що дивитися і чому.

Кейс 1. Вибір стратегії розгортання під конкретний ризик

Стратегію деплою обирають не за модою, а за співвідношенням «ризик проти інфраструктури». Таблиця розкладає три базові варіанти за осями, які реально впливають на роботу QA.

Як цим користуватися на практиці. Питання інтерв'юера чи тимліда «яку стратегію візьмемо?» — це насправді питання «який у нас ризик і що ми готові за нього заплатити». Критичний платіжний сервіс, де відкат має бути миттєвим, штовхає до blue-green або canary; проста стабільна внутрішня система з обмеженим бюджетом інфраструктури — до rolling.

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

Кейс 2. Playwright: post-deploy smoke і тест фіча-флага в обох гілках

Post-deploy smoke виконують проти живого URL середовища (а не проти зібраного білда), і він відповідає на одне питання: релізу можна довіряти чи відкочувати. Базовий набір — інфраструктура жива плюс один критичний наскрізний сценарій.

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

test('логін і кошик живі після деплою', async ({ page, request }) => {
  // 1) інфраструктура відповідає: health на реальному середовищі
  const health = await request.get(`${process.env.BASE_URL}/health`);
  expect(health.status()).toBe(200);

  // 2) один критичний наскрізний сценарій: увійти й відкрити кошик
  await page.goto('/login');
  await page.getByLabel('Email').fill(process.env.SMOKE_USER!);
  await page.getByLabel('Пароль').fill(process.env.SMOKE_PASS!);
  await page.getByRole('button', { name: 'Увійти' }).click();

  await page.goto('/cart');
  await expect(page.getByTestId('cart-page')).toBeVisible();
});

Фіча-флаг вимагає окремої дисципліни: той самий білд поводиться по-різному залежно від стану флага, тож стан треба задавати явно, а перевіряти обидві гілки — і on, і off.

test.describe('чекаут за фіча-флагом', () => {
  test.describe('флаг увімкнено', () => {
    test.use({ featureFlags: { 'new-checkout': true } });

    test('оплата йде новим флоу', async ({ page }) => {
      await page.goto('/checkout');
      await expect(page.getByTestId('checkout-v2')).toBeVisible();
    });
  });

  test.describe('флаг вимкнено', () => {
    test.use({ featureFlags: { 'new-checkout': false } });

    test('оплата йде старим флоу', async ({ page }) => {
      await page.goto('/checkout');
      await expect(page.getByTestId('checkout-v1')).toBeVisible();
    });
  });
});

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

• Smoke стукає в живий URL, а не в білд. process.env.BASE_URL вказує на конкретне середовище з його БД, конфігом і мережею. Саме тому smoke ловить те, що зелена регресія на PR пропускає: незмігровану базу, забуту змінну середовища, непіднятий процес.
• Стан флага задано явно, а не дефолтом. Якщо покладатися на дефолт середовища, той самий тест дає різний результат на різних стендах — це флак, тільки причина в конфігурації, а не в синхронізації. Явне featureFlags робить тест детермінованим.
• Перевіряємо обидві гілки, поки флаг живий. Стара й нова поведінка обидві в проді, доки флаг існує, тож off-гілку не можна лишати без тесту — саме на неї впаде kill switch, коли нову фічу доведеться вимкнути.
• N флагів — це 2^N конфігурацій. Увесь декартів добуток не перекриєш; бери релевантні комбінації за логікою попарного тестування, а мертві флаги (flag debt) вимагай прибирати, щоб простір не роздувався даремно.

Кейс 3. Перевірка валідності A/B перед тим, як вірити цифрам

Продакт каже: «варіант B підняв конверсію на 4%, розкочуємо». Перш ніж радіти, QA має підтвердити, що експерименту взагалі можна вірити. Три перевірки, на яких валяться A/B.

Перша — sample ratio mismatch: чи фактичний спліт відповідає заявленому. Заявлено 50/50, а прийшло помітно інакше — сплітер чи фільтрація зламані, і групи вже незіставні.

test('спліт відповідає заявленому 50/50 (немає SRM)', async ({ request }) => {
  const res = await request.get(`${process.env.BASE_URL}/api/experiments/checkout-ab/stats`);
  const { control, treatment } = await res.json(); // кількість користувачів у групах

  const total = control + treatment;
  const share = control / total;
  // груба межа для очевидного перекосу; для рішення потрібен статкритерій, це лише сигнал
  expect(Math.abs(share - 0.5)).toBeLessThan(0.02);
});

Друга — чистота трафіку: внутрішні прогони не мають падати в ту саму вибірку, що й реальні користувачі. Якщо сотні smoke-прогонів на день трекаються як конверсії, метрика зсунеться.

test('внутрішній трафік виключено з аналітики', async ({ page }) => {
  // тестовий акаунт має позначатися так, щоб аналітика його відфільтрувала
  const events: Array<Record<string, unknown>> = [];
  await page.route('**/analytics/collect', (route) => {
    events.push(route.request().postDataJSON());
    route.fulfill({ status: 204, body: '' });
  });

  await loginAsTestUser(page); // тестовий акаунт
  await page.goto('/checkout');
  await page.getByRole('button', { name: 'Оплатити' }).click();

  // подія конверсії має нести ознаку внутрішнього трафіку
  const conversion = events.find((e) => e.name === 'purchase_completed');
  expect(conversion?.internal).toBe(true);
});

Третя — коректність трекінгу: подія конверсії має спрацювати рівно один раз і приписатися правильному варіанту. Двійне спрацювання чи приписка не тому варіанту фальсифікують результат тихо.

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

• SRM — це стоп-сигнал, а не косметика. Помітний перекіс спліту означає, що з експериментом технічно щось не так (баг сплітера, фільтрація ботів зачепила один варіант). За наявності SRM «красивому» приросту конверсії вірити не можна — групи вже нерівнозначні. Точний вердикт дає статистичний критерій; тест вище лише ловить очевидний перекіс як ранній сигнал.
• Внутрішній трафік забруднює метрику найпростіше. QA-прогони, автотести, боти, співробітники мусять або виключатися, або йти в окремий сегмент. Ознака internal у події — саме те, за що чіпляється фільтр аналітики.
• sticky-призначення (sticky assignment) — окрема перевірка. Один користувач має бачити той самий варіант між візитами; якщо варіант мерехтить, досвід зламаний і дані брудні. Це перевіряють стабільністю призначення по одному й тому самому ідентифікатору.
• Guardrail-метрики не забуваємо. Навіть валідний приріст цільової метрики — не перемога, якщо поряд зросли помилки чи просіла швидкість. QA дивиться не лише на «цифру, яку хотіли підняти», а й на захисні показники.

Середовища й паритет

• Можу пояснити, що середовище — це окремий екземпляр застосунку з власною інфраструктурою, БД і конфігурацією, а не інша копія коду.
• Знаю призначення драбини dev → staging → prod і що кожна сходинка ловить свій клас проблем.
• Розумію поняття паритету середовищ і чому staging завжди трохи бреше (версії залежностей, конфіги, флаги, CDN).

Деплой, реліз і smoke

• Можу чітко розвести деплой (код на середовищі) і реліз (фіча доступна користувачам) і пояснити, що їх розводить фіча-флаг.
• Знаю, що post-deploy smoke націлений на конкретне розгортання на живому середовищі, а регресія на PR — на код до злиття проти тестового білда.
• Можу назвати мінімум для smoke: health 200, головна рендериться, логін працює, один-два критичні наскрізні сценарії.
• Розумію, чому smoke має бути швидким і стабільним і чому в зрілому пайплайні його провал тригерить автоматичний відкат.

Стратегії розгортання

• Знаю різницю rolling vs blue-green vs canary за трьома осями: одночасність версій, спосіб і швидкість відкату, потреба в інфраструктурі.
• Розумію, чому blue-green дає миттєвий відкат (перемикання балансувальника) ціною подвійної інфраструктури.
• Можу пояснити, чому canary дає найкращий контроль ризику й навіщо йому пороги метрик (error rate, p95-латентність).
• Знаю, що роль QA — задати критерії просування/відкату й перевірити зворотну сумісність (expand-contract), а не «клацнути після деплою».

Feature flags і A/B

• Можу пояснити, як фіча-флаг розриває зв'язок деплой/реліз і чому kill switch — найшвидший відкат.
• Знаю, що стан флага в тесті треба задавати явно, і що інакше тест «іноді зелений» — це флак від конфігурації.
• Розумію комбінаторний вибух 2^N і що покривати треба релевантні комбінації, а не декартів добуток; знаю, що таке flag debt.
• Знаю, що таке SRM (sample ratio mismatch) і чому за нього результатам експерименту вірити не можна; можу назвати guardrail-метрики.

Rollback і версіонування

• Можу пояснити, чому код відкотити легко, а дані ні, і як expand-contract дозволяє відкотити код без зміни схеми БД.
• Можу розшифрувати SemVer MAJOR.MINOR.PATCH: MAJOR — breaking, MINOR — нова сумісна фіча, PATCH — фікс.
• Розумію ^1.2.0 vs ~1.2.0 і чому діапазони версій дають «нічого не міняв, а зламалось»; знаю роль lock-файлу.

Testing in production

• Можу назвати техніки testing in production: canary + флаги, synthetic monitoring, shadow traffic, A/B і RUM.
• Знаю три залізні запобіжники: не псувати реальні дані, обмежувати радіус ураження, мати спостережуваність і швидкий kill switch.