Від перевіреної зміни до контрольованого випуску

Глава 56 про неперервну інтеграцію (Continuous Integration, CI) пояснила, як автоматичні перевірки повідомляють про конкретну ревізію коду. Тепер простежимо шлях далі: як команда готує зміну до випуску, доставляє її в потрібне середовище, перевіряє поведінку й вирішує, чи показувати її користувачам. У цій темі скорочення CD має два значення: неперервна доставка (Continuous Delivery) означає, що зміни можна випустити на вимогу; неперервне розгортання (Continuous Deployment) — що кожну зміну, яка пройшла визначені умови, автоматично розгортають у виробниче середовище (production). Програма дослідження доставки програмного забезпечення та операційної діяльності (DevOps Research and Assessment, DORA) розрізняє ці практики: команда може підтримувати постійну готовність до випуску й водночас чекати на явне рішення перед production. DORA описує обидва значення CD окремо.

Після цієї глави читач може:

• відрізнити збірку, артефакт, випуск коду, розгортання та ввімкнення можливості для користувачів;
• простежити один перевірений артефакт від збірки до середовищ і перевірити, чи саме його просувають далі;
• пояснити, які автоматичні й людські умови мають зупинити або дозволити випуск;
• виявити ризик несумісної зміни даних, навіть якщо нова функція прихована прапорцем;
• назвати докази, потрібні після розгортання, та визначити першу безпечну дію, коли вони погані;
• окреслити, які підготовчі завдання можна доручити агенту, не надаючи йому невизначеного доступу до production.

57.1. Шість різних подій

Злиття (merge) включає перевірену зміну до цільової гілки коду. Воно може запустити подальший workflow, але саме по собі не розгортає нову версію й не відкриває її користувачам. Збірка перетворює код і визначені залежності на пакет, який можна запустити або розмістити: наприклад, архів вебзастосунку чи образ контейнера. Артефакт — це саме цей пакет разом з ідентифікатором і доказами його походження. Розгортання встановлює артефакт у середовище або змінює його конфігурацію. Випуск означає, що зміна стала доступною цільовим користувачам. Ввімкнення (enablement) — окреме рішення зробити конкретну функцію доступною, наприклад, перемкнути прапорець або додати групу користувачів до rollout. Випуск може відбутися під час розгортання, але може й пізніше — наприклад, коли відповідальна людина відкриває доступ через прапорець функції.

Отже, команда може розгорнути незавершений код у production, залишити нову можливість вимкненою й не випустити її користувачам. Так само програма для телефону може бути готова до публікації, але чекати на рішення про дату випуску в магазині застосунків. Ці приклади показують різні переходи, а не окремі універсальні етапи, які мусять бути в кожному pipeline.

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

Мета тут не в тому, щоб випускати зміни якомога частіше незалежно від якості. DORA застерігає, що збільшення частоти без покращення процесу й архітектури може підвищити частоту збоїв і виснаження команди. Цінність неперервної доставки походить від готового до випуску стану, невеликих змін, швидкого зворотного зв’язку, надійних перевірок і спостереження за результатом. DORA: Continuous delivery.

Наявність кроку в сценарії автоматизації не означає, що це обов’язкова умова злиття або випуску. Умову треба реально налаштувати як gate — перевірку, без проходження якої наступна дія не може відбутися. У GitHub Actions, наприклад, для цього можна прив’язати job до середовища з правилами схвалення або обмеженням гілок. Сам факт, що workflow звернувся до названого environment, не говорить, які саме захисти налаштовано в репозиторії. Документація GitHub про середовища й правила захисту.

57.2. Створити один артефакт і простежити його шлях

Програма DORA радить використовувати ту саму збірку для всіх середовищ: тоді production отримує той самий пакет, який команда перевірила раніше. Збірка повинна мати незмінний ідентифікатор — наприклад, повний ідентифікатор ревізії коду та криптографічний відбиток пакета. Людський тег на кшталт latest зручний для пошуку, але його можуть пересунути на інший пакет; сам по собі він не доводить, який саме вміст розгорнули.

Збірка й розгортання також мають залишати докази, які можна звірити: з якої ревізії зібрано пакет, яким workflow та інструментами, які перевірки пройшли, куди його розгортали, хто погодив перехід і який результат спостерігали. Підписане підтвердження походження (attestation) може криптографічно пов’язати артефакт з workflow, репозиторієм, ревізією, середовищем і подією, що запустила збірку. Воно підтверджує походження пакета, але не гарантує, що пакет безпечний або поводиться правильно: споживач має перевірити підпис і застосувати власні правила прийняття. GitHub пояснює склад підтвердження походження та його межі.

Робочий артефакт перевірки не завжди є довгостроковим сховищем релізів. Артефакти workflow зберігаються за політикою терміну дії, яку можуть обмежувати репозиторій, організація або підприємство; поточні налаштування GitHub за замовчуванням зберігають їх 90 днів. Для продукту, якому потрібно відновити давній реліз або виконати аудит через рік, оберіть реєстр пакетів чи інше сховище з потрібним строком і політикою збереження. GitHub: артефакти й термін їх зберігання, налаштування терміну зберігання.

Окремими можуть бути конфігурація середовища й секрети, потрібні конкретному запуску: адреса зовнішнього сервісу, параметр масштабування або пароль інтеграції. Однак така переносимість не виникає автоматично. Деякі значення потрапляють у пакет під час збірки; зміна середовища тоді може вимагати нової збірки. Команда має знати, яка конфігурація застосовується на етапі збірки, а яка — під час розгортання, і перевірити, що вона не підміняє ідентичність самого артефакту.

Для прикладу уявімо сервіс бронювання, що додає електронне підтвердження. Збірка з ревізії 92ac1bf створила образ registry.example/booking@sha256:8a2d…; sha256 тут позначає відбиток за алгоритмом SHA-256 (Secure Hash Algorithm, 256-бітна версія). Перевірки підтвердили основні сценарії, а workflow записав посилання на результати й походження образу. У середовищі попереднього перегляду (preview) тестують основний сценарій на цьому образі; у передвиробничому середовищі (staging) розгортають той самий відбиток, але з тестовою базою й тестовим поштовим сервісом. Після успішної перевірки production отримує цей самий образ, а власник релізу окремо погоджує час і дозволяє поступове відкриття функції.

Якщо production натомість збирає код повторно з тієї самої гілки, образ уже інший. Він може містити нові залежності, інший код генерації або іншу конфігурацію. Тест staging тоді не є прямим доказом для production-пакета. Контрольована доставка просуває саме перевірений об’єкт між середовищами, а не покладається на схожість назв версій.

Етап	Що звірити
Збірка	Ревізія коду, ідентифікатор пакета, результати обов’язкових перевірок, доступне підтвердження походження
Preview або staging	Той самий відбиток пакета, версія конфігурації, успіх критичного сценарію й відомі обмеження тестових інтеграцій
Production	Той самий відбиток, погодження потрібних людей або правил, версія конфігурації, час і середовище розгортання
Після розгортання	Ключові користувацькі сценарії, помилки й затримки, відмінності від базового рівня, рішення продовжити чи зупинити

57.3. Що саме відкриває наступний етап

Рішення просувати пакет може спиратися на кілька різних доказів. Не варто зводити їх до одного повідомлення «зелено».

• Автоматизована перевірка підтверджує конкретну властивість: наприклад, що основний сценарій бронювання проходить у тестовому середовищі.
• Огляд людиною перевіряє контекст, який код не може надійно визначити: межі впливу, відповідальних і час розгортання.
• Захист середовища технічно затримує production-job, доки не виконано задану умову. У GitHub Actions це може бути схвалення reviewer-ом, таймер очікування чи обмеження гілки. Налаштування й доступність цих правил залежать від типу репозиторію та тарифного плану GitHub.
• Спостереження після розгортання показує, як реальна система поводиться для користувачів. Воно має вимірювати не тільки факт запуску процесу, а й важливі результати продукту.
• Рішення про випуск функції визначає, коли й для кого стане доступною поведінка. Для нього можуть бути потрібні продуктова готовність, сумісність із партнерами або поетапний доступ.

Чітко визначте, хто може зупинити перехід і за якими ознаками: стрибок помилок, збільшення часу відповіді, невдалий критичний сценарій, недоступність залежності, некоректні дані чи невідповідність відбитка пакета. Числові пороги треба встановлювати за звичайним рівнем і допустимим ризиком саме цієї системи. Універсальний відсоток і кількість хвилин тут не допоможуть.

Ручне схвалення — лише одна з умов; воно не замінює перевірку артефакту, здоров’я системи чи сумісності даних. І навпаки, якщо політика вимагає людського дозволу, самої успішної автоматичної перевірки недостатньо. У GitHub середовище з required reviewers зупиняє job до схвалення, а секрети цього середовища стають доступними job-у лише після нього. GitHub: deployment protection rules і environment secrets.

Платформа також може видати workflow короткостроковий токен замість постійного ключа хмарного облікового запису. GitHub Actions підтримує OpenID Connect (OIDC) — відкритий протокол, за яким workflow запитує посвідчення, а хмарний провайдер обмінює його на тимчасовий токен доступу. Сам дозвіл id-token: write дозволяє лише запросити токен у провайдера GitHub; він сам по собі не дає права змінювати хмарні ресурси. Власник хмарного акаунта має окремо налаштувати довіру, перевірити твердження про репозиторій і workflow та надати ролі лише потрібні операції. GitHub: OpenID Connect у workflow та обмін токенів.

57.4. Сумісність коду, конфігурації та даних

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

Розгляньмо сервіс бронювання, який зберігав час початку у полі start_time. Нова версія хоче перейти на окреме поле starts_at_utc; у цій назві UTC означає координований всесвітній час (Coordinated Universal Time, UTC). Безпечний перехід може виглядати так:

1. Розширити схему: додати нове поле, залишивши старе. Переконатися, що попередня версія продовжує запускатися.
2. Навчити код сумісності: новий код читає старе й нове значення та тимчасово записує обидва. Старі процеси можуть і далі читати старе поле.
3. Перенести й перевірити дані: заповнити нове поле порціями, порівняти кількість записів та інваріанти; окремо виявити значення, які не можна безпечно перетворити.
4. Перемкнути читання: після перевірки змусити код читати нове поле. Спершу залишити старе, щоб повернення до сумісної версії не зламало роботу.
5. Скоротити стару схему: видалити застаріле поле лише після того, як команда підтвердила, що старі версії, фонові споживачі й потрібний шлях відновлення його більше не використовують.

Це навчальний варіант підходу «розширити — перенести — скоротити»; конкретний порядок і транзакційність залежать від системи зберігання, драйвера, обсягу даних і навантаження. Детальні ризики блокувань, пакетного backfill і зворотної сумісності розібрані у [главі 52 про міграції бази даних](52-database-migrations.md).

Перевірте конфігурацію так само, як код. Production-адреса партнера, дозволи облікового запису, увімкнений формат шифрування чи значення feature flag можуть змінити поведінку того самого пакета. Зберігайте конфігурацію у версійному або аудитованому місці, призначайте власника, обмежуйте права і не включайте секрети в образи, логи чи публічні артефакти. Для workflow, який отримує доступ до хмарної системи, віддавайте перевагу короткоживучому токену з чіткими умовами довіри, якщо провайдер і архітектура це підтримують.

57.5. Прапорець функції не є машиною часу

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

Прапорець впливає лише на код, який його перевіряє. Він не скасовує вже застосовану міграцію, не відновлює видалені дані, не зупиняє фонове завдання, яке прапорець ігнорує, і не повертає зміни сторонньої системи. Якщо новий код записав дані в несумісному форматі, просте вимкнення прапорця може приховати екран, але залишити систему в неузгодженому стані.

Не залишайте перехідні прапорці без власника. Запишіть, хто й коли його перемикає, яке значення вважається старою поведінкою, як перевіряється кожна гілка, які користувачі мають його бачити та коли прапорець буде видалений. Fowler окремо описує release-, experiment- та ops-прапорці: ці категорії мають різні цілі й строк життя; безконтрольне змішування створює довготривалий код, який ніхто не розуміє. Martin Fowler, Feature Toggles.

Повний розбір: прапорець вимкнений, але міграція вже несумісна

У навчальному сервісі доставки команда додає новий тип адреси для пункту видачі. Вона розгортає код із прапорцем pickup-address-v2, вимкненим для всіх користувачів. Та сама версія вже виконує міграцію: змінює старе поле адреси так, що старі процеси не можуть його прочитати. Фонове завдання починає записувати новий формат незалежно від того, чи прапорець приховує новий елемент користувацького інтерфейсу (user interface, UI).

Команда бачить помилки у старому екземплярі й вимикає pickup-address-v2. Форма для користувачів ховається, але фоновий запис триває, а старий код падає на нових значеннях. Спроба просто розгорнути попередній артефакт не допомагає: він також не читає змінену схему. Перемикач змінив видимість функції, але не змінив уже записані дані й не повернув старі правила сумісності.

Перед розгортанням команда мала б спершу додати нове поле без руйнування старого формату, навчити обидві версії співіснувати, перевірити записи та фонові процеси, потім за прапорцем перемкнути користувацьку поведінку. Стару схему можна скоротити лише після виведення старого коду з роботи й завершення періоду, коли потрібне повернення до нього. Якщо несумісні дані вже з’явилися, перший крок — зупинити їх подальше створення й визначити, чи безпечне відновлення; залежно від наслідків може знадобитися виправлення вперед, а не простий rollback. Це вигаданий приклад; він застосовує принципи сумісності, розібрані в главі 52.

57.6. Після розгортання перевірте результат для користувача

Job може завершитися зі статусом успіху, бо команда копіювання файлів відпрацювала, а контейнер запустився. Це ще не доводить, що користувач може виконати потрібну дію. Перевірки після розгортання мають перевірити:

• готовність процесу: він запустився, бачить потрібні ресурси й може приймати запити;
• основний сценарій: нове бронювання, платіж або імпорт завершується очікуваним результатом;
• зовнішні залежності: інтеграції доступні з production-обліковими даними й мають потрібні дозволи;
• показники поведінки: частота помилок, затримка й частка успішних сценаріїв залишаються в прийнятних межах;
• цілісність даних: нові записи мають очікуваний формат, а фонові задачі не створюють розбіжностей.

Повний розбір: зелений job, неправильний ключ партнера

У синтетичному прикладі сервіс бронювання отримує нову версію без помилок. Перевірка процесу проходить: endpoint здоров’я доступний, вебсторінка відкривається, контейнер працює. Але production-інтеграція з платіжним партнером має неправильний ключ: запити партнера відхиляються, а нові оплачені бронювання не підтверджуються.

Чому зелений job не виявив проблему? Його smoke test перевіряв лише запуск застосунку, а тест staging використовував інший ключ і тестовий акаунт. Команда не запускала реальний нешкідливий end-to-end сценарій у production і не стежила за відсотком успішних відповідей партнера. Таким чином, автоматизація довела технічне розгортання, але не правильність production-конфігурації чи результат для користувача.

Перша безпечна дія — припинити подальше відкриття функції або зупинити новий rollout; не повторювати спроби платежу без контролю, щоб не створити дублікати. Потім власник інтеграції звіряє середовище, ідентичність ключа, його дозволи й строк дії, не друкуючи секрет у лог. Команда перевіряє невдалі бронювання та план їх безпечної обробки, після чого змінює секрет у відповідному сховищі й проходить критичний сценарій з безпечною тестовою операцією або контрольованою production-перевіркою. Якщо помилка лише в конфігурації, перебудова коду може бути зайвою; якщо в коді переплутано середовища, знадобиться новий перевірений пакет. Це вигаданий приклад, який показує, чому доказ про стан процесу відрізняється від доказу про роботу продукту.

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

57.7. Обмежте вплив і заздалегідь визначте зупинку

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

У наступній главі стратегії розгортання будуть розібрані докладніше. Тут достатньо запам’ятати: «розгорнути на невеликій кількості» без окремої перевірки цього сегмента — не канарковий rollout. Канарковий запуск розгортає зміну на обмежену частину системи на визначений час і порівнює її поведінку з контрольною групою. Якщо показники нової версії погіршилися, pipeline має зупинити просування й дозволити відкочування або звернутися до відповідальної людини. Фахівці Google Site Reliability Engineering (SRE — інженерна надійність сервісів) радять обирати вимірювані сигнали й враховувати тривалість етапу, обсяг трафіку, репрезентативність і спільні залежності. Google SRE Workbook, Canarying Releases.

Відновлення потрібно спланувати до першого production-випуску: знати останню перевірену версію, власника рішення, команду для зупинки та наслідки повторного запуску. Відкат (rollback) повертає попередній програмний артефакт або конфігурацію, щоб відновити попередній стан системи; виправлення рухом уперед (forward fix) змінює поточний стан новою зміною. Це різні шляхи, а не взаємозамінні кнопки. Якщо зміна лише замінила програмний артефакт, повернення попереднього може бути простим. Якщо змінилися схема, збережені дані, зовнішні відправлення або права доступу, повернення бінарного файлу не скасує цих наслідків. Збережіть контрольні точки, підтвердьте сумісність старої версії й перевірте процедуру відновлення заздалегідь. Докладніше — у главі 60 «Відкат і відновлення».

Першоджерельний випадок: конфігурація YouTube і урок про канарковий rollout

У ретроспективі Google SRE описує глобальний збій YouTube 2016 року через помилку в розподіленій системі кешування пам’яті. Сторінка «Lessons learned» підсумовує збій як п’ятнадцятихвилинний; у пов’язаному уроці «Canary all changes» описано конфігураційну зміну кешу, яка серйозно порушила роботу сервісу на тринадцять хвилин. Там сказано, що поступове розгортання могло обмежити глобальний вплив. Опубліковане джерело не містить точного файла конфігурації, усіх кроків зміни чи повного таймлайну; згадка про користь канаркового розгортання є інженерним висновком авторів, а не виміряним доказом того, як пройшов би альтернативний реліз. Google SRE: Lessons learned from two decades of SRE, розділ про canary releases.

Цей випадок показує, що конфігурація теж може бути релізом із великим радіусом впливу. Перевірка короткого job або відсутність помилки в синтаксисі не доводять, що нове значення безпечне для всього трафіку. Розгортайте такі зміни поступово, порівнюйте відповідні показники нової та контрольної груп, заздалегідь визначте критерій зупинки й відпрацюйте процедуру відновлення. Окрема публікація Google SRE про цей інцидент також застерігає, що неперевірене аварійне відновлення може посилити збій замість виправити його.

57.8. Де може допомогти агент

Агент може зібрати для відповідального за реліз контекст: що змінено, який відбиток зібрано, які перевірки виконані, який пакет зараз у staging, які показники змінилися та чого не вистачає для рішення. Він може підготувати нотатки до випуску, таблицю доказів і чернетку плану спостереження. Висновок агента треба звірити з першоджерельними checks, ідентифікаторами артефакту та вимірюваннями, а не приймати за окремий дозвіл на deployment.

GitHub прямо радить застосовувати agentic workflows для підготовки нотаток до випуску, аналізу змін і звітів про rollout, залишаючи саме розгортання детермінованим workflow. GitHub: Continuous deployment. Codex GitHub Action може запускати codex exec з явно заданими дозволами й режимом sandbox та передавати останнє повідомлення як вихід; OpenAI окремо радить обмежити, хто запускає workflow, санітизувати текст запиту на злиття (pull request, PR) і захищати секрет OPENAI_API_KEY. OpenAI: Codex GitHub Action. Claude Code GitHub Action може отримати actions: read, щоб читати результати неперервної інтеграції (CI), а документація також описує дозволи GitHub App на запис для внесення змін і відповіді на запити. Ці права залежать від налаштування workflow та встановленої програми, а не від самого факту використання моделі. Anthropic: Claude Code GitHub Actions.

Для навчальної release assistant схеми достатньо доступу лише для читання до змін, перевірок і метаданих артефакту. Не передавайте йому production-секрети, хмарний токен або право обходити захист середовища, якщо його робота — тільки підготувати рішення. Якщо організація свідомо автоматизує розгортання, права workflow мають бути обмежені конкретним репозиторієм, гілкою, середовищем, дією й строком життя токена; production-gate має залишатися явним і перевірятись у налаштуваннях платформи.

Короткий підсумок

Неперервна доставка підтримує зміну в готовому до випуску стані; неперервне розгортання автоматизує перехід за визначеними умовами. Простежуйте незмінний ідентифікатор одного артефакту від збірки до середовищ, відокремлюйте конфігурацію, а походження пакета звіряйте з результатами перевірок. До production плануйте gates, сумісність старого й нового коду, міграції, показники після розгортання та реальний шлях зупинки. Прапорець функції допомагає контролювати видимість поведінки, але не повертає дані чи схему назад. Агент може підготувати докази й план; право на виробничу дію має визначати конкретна workflow-політика й мінімально потрібні дозволи.

Джерела та подальше читання

Матеріали перевірено 24 вересня 2026 року. Сторінки документації, що змінюються без нумерації версій, наведені як актуальні на цю дату; перед налаштуванням виробничої системи повторно звірте функції, тарифи, permissions і поведінку обраної платформи.

• DORA, Continuous delivery — розрізнення неперервної доставки та неперервного розгортання; CI, автоматизоване розгортання, спостереження й керування змінами даних як окремі спроможності.
• DORA, Deployment automation — ті самі пакети для різних середовищ, конфігурація середовища окремо від пакета, тест після розгортання та збереження стану середовища.
• GitHub Actions, Continuous deployment — сценарії запуску CD, середовища, concurrency, OIDC та роль agentic workflows у підготовці випуску.
• GitHub Actions, Deployments and environments — required reviewers, таймери, обмеження гілок і доступ до environment secrets.
• GitHub Actions, Workflow artifacts і artifact retention settings — призначення workflow artifacts і межі строку зберігання.
• GitHub Actions, Artifact attestations та Using attestations — підписані дані про походження, можливість прив’язати пакет до переліку компонентів програмного забезпечення (Software Bill of Materials, SBOM), права генерації та перевірка споживачем; attestation сама по собі не є гарантією безпеки.
• GitHub Actions, OpenID Connect — обмін посвідчення workflow на короткострокові хмарні токени й налаштування довіри.
• Google SRE Workbook, Canarying Releases — контрольна група, вибір метрик і тривалості та рішення зупинити або просунути кандидат.
• Google SRE, Lessons learned from two decades of SRE — оприлюднені уроки про збій YouTube, ризик конфігураційних змін і тестування відновлення.
• Google SRE, Configuration Design and Best Practices — поступове розгортання конфігурацій, відновлення та межі rollback.
• Martin Fowler, Feature Toggles (aka Feature Flags) — категорії прапорців, відокремлення deployment від release та обслуговування перехідних прапорців.
• OpenAI, Codex GitHub Action — sandbox, workflow-права, вихідні повідомлення агента й security checklist.
• Anthropic, Claude Code GitHub Actions — режими запуску, можливість читати результати неперервної інтеграції (CI), дозволи GitHub App і захист секретів.
• [Глава 52 курсу про міграції бази даних](52-database-migrations.md) — докладніше про сумісність схеми, backfill, перевірки й вибір між rollback та forward fix.