Урок 01 · 12 хв

CI, CD і анатомія workflow

Чим доставка відрізняється від розгортання і з чого складається YAML-файл GitHub Actions.

12 хвУрок 1 з 5Є практикаAsk AI до кожного пункту

Про що цей курс

Урок 1. CI, continuous delivery і continuous deployment, анатомія workflow.
Урок 2. Конвеєр для Node і TypeScript: кеш, lint, типи, тести, збірка, матриця версій.
Урок 3. Секрети, змінні, environments із ревʼюерами, права GITHUB_TOKEN, OIDC замість довгоживучих ключів.
Урок 4. Артефакти, Docker-образ у registry, deploy jobs і concurrency.
Урок 5. Безпечні релізи: захист гілок, стратегії деплою, відкат, reusable workflows, pinning за SHA.
У планах: self-hosted runners, конвеєри для монорепо, безпека сторонніх actions на практиці.

У курсі DevOps ми вже запускали мінімальний CI: checkout, встановлення, lint, тести. Тут ідемо глибше: як влаштований workflow, як зробити його швидким, безпечним і довести код до продакшену так, щоб відкат займав хвилину.

Можна спитати про цей пункт«Про що цей курс»

Три терміни, які плутають

Continuous integration (CI): кожна зміна вливається в спільну гілку часто, і кожну автоматично перевіряють: збірка, lint, тести. Мета: зламаний код не доходить до main.
Continuous delivery (CD): кожен зелений коміт у main готовий до релізу. Артефакт зібраний, перевірений і може піти в прод одним рішенням людини, наприклад кнопкою або approve.
Continuous deployment: той самий конвеєр, але без людини. Зелений main сам їде в продакшен. Це вимагає дуже доброго покриття тестами, моніторингу й автоматичного відкату.

Можна спитати про це правило«Абревіатура CD двозначна»

Можна спитати про цей пункт«Три терміни, які плутають»

З чого складається workflow

Workflow це YAML-файл у .github/workflows/. У ньому є тригер (on), один або кілька jobs, а в кожному job steps. Jobs за замовчуванням ідуть паралельно на окремих віртуальних машинах (runners). Steps усередині job виконуються послідовно на одній машині й ділять файлову систему.

.github/workflows/ci.yml

on: події, які запускають workflow. Найчастіші: push, pull_request, workflow_dispatch (вручну), schedule (cron), release, workflow_call (виклик з іншого workflow).
runs-on: де виконувати job. ubuntu-latest, windows-latest, macos-latest або мітки власних runners.
needs: залежність між jobs. Без неї jobs стартують одночасно.
if: умова на job або step, наприклад if: github.ref == 'refs/heads/main'.

Можна спитати про цей пункт«З чого складається workflow»

uses проти run

Step буває двох видів. run виконує shell-команду на runner. uses підключає готовий action: шматок коду з іншого репозиторію (actions/checkout@v4), з цього ж репозиторію (./.github/actions/setup) або Docker-образ. Параметри action передають через with, змінні середовища через env.

Обидва види в одному job

Можна спитати про це правило«Кожен job стартує з чистої машини»

У базі знань

GitHub Actions: коротка довідка
GitLab CI: той самий підхід в іншому інструменті
GitHub Actions чи GitLab CI

Можна спитати про цей пункт«uses проти run»

Перевірка

Закріпи, поки не пішов далі

1. Чим continuous delivery відрізняється від continuous deployment?
2. Як за замовчуванням виконуються два jobs без needs?
3. Що робить step з ключем uses?
4. Step зібрав dist/. Де ця тека буде доступна без додаткових дій?

ПрактикаРозв’яжи задачі урокуКілька коротких завдань у редакторі. Перевіряй код одразу й бач, де помилка.Почати практику