CI/CD пайплайни з GitHub Actions: від нуля до продакшену

Мінімальний робочий пайплайн

GitHub Actions описується декларативно через YAML-файли в .github/workflows/. Навіть простий пайплайн варто розбивати на явні послідовні кроки — збірку, тести і деплой — щоб помилка на кожному етапі була видна одразу, а не губилася в загальному логу.

name: ci
on: [push]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run build
      - run: npm test
``` Детальніше про суміжний підхід можна прочитати в матеріалі [«Blue-Green і Canary деплой: різниця та коли застосовувати»](/devops/blue-green-canary-deploy).

![Три послідовні етапи пайплайна](/images/content/devops/cicd-github-actions/diagram.png)

## Кешування і деплой

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

Деплой краще виносити в окремий job, який запускається лише після успішного проходження тестів і лише для певної гілки, наприклад `main`, через умову `if: github.ref == 'refs/heads/main'`. Секрети на кшталт токенів доступу до сервера чи хмари зберігаються в GitHub Secrets і ніколи не потрапляють у код пайплайна у відкритому вигляді. Ці ідеї перегукуються з темами [«Інфраструктура як код з Terraform: найкращі практики»](/devops/terraform-best-practices) та [«Індекси в PostgreSQL: як прискорити повільні запити»](/databases/postgresql-indexes).