Демонстрація / навчальна демонстрація
Приклад CI/CD pipeline: перевірка, збірка та керований реліз
Це статичний навчальний приклад, а не pipeline клієнта чи готовий deployment у вашій інфраструктурі. Він показує зв'язок перевірок, артефакту й рішення про реліз без хмарного акаунта або платного сервісу.
Вхід і результат кожного етапу
Вхід pipeline — конкретна ревізія коду та зафіксовані залежності. Результат перевірки має стосуватися саме цієї ревізії. Якщо release-job непомітно забирає новішу гілку, попередній зелений статус уже не описує те, що запускається.
Для невеликого Next.js-проєкту початковий gate може складатися з lint, TypeScript і production-build. За наявності бізнес-логіки додаються потрібні тести. Сама збірка не підтверджує, що лист доставляється або база доступна.
sh
# Перевірка коду; запускати в checkout потрібної ревізії
pnpm install --frozen-lockfile
pnpm lint
pnpm typecheck
pnpm build
# Далі: пакування артефакту → release gate → deployment
# Команди деплою залежать від hosting і тут навмисно не задані.Один перевірений артефакт
У пропонованій схемі build створює артефакт з ідентифікатором ревізії. Реліз просуває цей самий результат, а не збирає код заново без потреби. Параметри середовища, які вбудовуються під час збірки, треба врахувати до пакування.
Секрети production не додаються до публічних frontend-змінних або архіву. Перед вибором контейнера чи іншого формату команда має знати, як hosting очікує отримати й запустити застосунок.
text
commit → install → lint + typecheck → build → artifact(revision)
↓
release approval / policy
↓
deploy → smoke check
↓
keep release або rollbackЯк поводитися при помилці
Якщо перевірка або збірка не пройшла, новий артефакт не переходить у реліз. Якщо збій трапився після deployment, потрібне рішення за результатами smoke check: виправити конфігурацію, повернути попередній артефакт або зупинити подальші зміни.
| Етап | Приклад перевірки | Дія при відмові |
|---|---|---|
| До build | Типи й lint | Зупинити pipeline, виправити ревізію. |
| Після build | Артефакт існує й має ідентифікатор | Не запускати невідомий або неповний результат. |
| Після deploy | Головна й критичний API доступні | Застосувати погоджений план відновлення. |
| Після міграції | Дані та стара версія сумісні | Діяти за окремим планом даних, не лише відкотити код. |
Мінімальна репетиція rollback
До першого важливого релізу виберіть відомий справний артефакт, перевірте спосіб його повторного запуску й зафіксуйте відповідального. Для зміни схеми даних потрібен окремий аналіз сумісності: повернення контейнера не відновлює автоматично видалені записи.
У навчальному сценарії можна навмисно зламати перевірку типів і переконатися, що deployment не починається. Другий сценарій — невдалий smoke check у тестовому середовищі та відновлення попереднього релізу.
Як адаптувати приклад до вашої команди
Потрібні три рішення: де зберігається артефакт, хто й за яких умов запускає production, як перевіряється результат. Далі додаються конкретні hosting-команди, короткоживуча авторизація, обмеження паралельних релізів і спостереження за помилками.
Починайте з відтворюваного простого процесу. Kubernetes, велика система approval або багато сканерів мають сенс лише тоді, коли вирішують вашу конкретну задачу.
Джерела та контекст
Маєте подібну задачу?
Розкажіть про продукт, поточні обмеження й потрібний результат — визначимо предметний наступний крок.