Що таке GitHub Actions: автоматизація для розробників без окремого сервера

Що таке GitHub Actions і чому окремий CI-сервер більше не потрібен кожному

Раніше, щоби автоматизувати тестування коду, треба було:

мати окремий сервер з Jenkins / Travis CI / GitLab CI;
налаштовувати вебхуки з GitHub на свій сервер;
слідкувати за оновленнями, безпекою і доступністю цього сервера;
платити за інфраструктуру, навіть якщо тобі треба лише запускати тести раз на день.

GitHub Actions вирішує це інакше: ти просто додаєш YAML-файл у свій репозиторій — і GitHub сам запускає тести, білди й деплої на своїх серверах. Нічого встановлювати, нічого адмініструвати.

Просто: ти описуєш, що треба зробити. GitHub робить це за тебе.

Проблема / контекст: чому без автоматизації — це ризик

Без CI (Continuous Integration) все працює вручну: хтось зробив коміт, хтось інший локально запустив тести, і все закінчилось «наче працює». Але коли:

коміти відбуваються часто (декілька на день);
команда з кількох людей;
є залежності від третіх сервісів (база даних, API);
деплой має бути надійним;

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

GitHub Actions робить так, що кожен коміт автоматично перевіряється. Не людина вирішує, чи тестувати — це відбувається завжди.

Як це працює простими словами

GitHub Actions працює за такою моделлю:

1. Workflow — опис того, що треба зробити

Це YAML-файл в папці .github/workflows/ твого репозиторію. Наприклад .github/workflows/test.yml:

name: Run tests
on:
  push:
    branches: [main, master]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test

Розберемо:

name — назва workflow (видно в інтерфейсі GitHub).
on — коли запускати (push у main або master).
jobs — список завдань. Тут одне завдання test.
runs-on — на якому сервері виконувати (остання версія Ubuntu).
steps — кроки: checkout коду, встановлення Node.js, установка залежностей, запуск тестів.

2. GitHub бачить зміни і запускає

Коли хтось пушить код у main, GitHub знаходить YAML-файл, читає його і запускає workflow. На вкладці Actions у репозиторії ти бачиш статус: зелений ✓ (успіх) чи червоний ✗ (помилка).

3. Раннер виконує кожен крок

GitHub виділяє віртуальний сервер (runner), клонує твій репозиторій, виконує кожен крок по черзі і звітує про успіх чи помилку.

4. Залежності між jobs

Якщо потрібно збірка перед тестами:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build

  test:
    needs: build  # test чекає, поки build завершиться
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

Найпоширеніші сценарії

1. Автоматичне тестування коду

Найпростіший і найкорисніший старт. Кожен коміт — автоматичні тести. Якщо тести падають — ти дізнаєшся одразу, а не через місяць.

2. Деплой у production після тестів

  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - run: ./deploy.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Секрети (secrets.DEPLOY_TOKEN) зберігаються в налаштуваннях репозиторію і не потрапляють в код.

3. Деплой у staging на pull request

  deploy-staging:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - run: ./deploy-staging.sh

Так можна перевіряти зміни на тестовому сервері ще до злиття в основну гілку.

4. Періодичні задачі — розклад

  nightly:
    runs-on: ubuntu-latest
    on:
      schedule:
        - cron: '0 2 * * *'  # щодня о 02:00 UTC
    steps:
      - run: ./nightly-check.sh

Типові помилки

1. Хардкодити секрети в workflow

Токени, паролі, ключі не повинні бути в YAML. Використовуй secrets. — вони зберігаються в налаштуваннях репозиторію і не потрапляють в історію комітів.

2. Ігнорувати версії actions

actions/checkout@v4 — це конкретна версія. Не пиши actions/checkout@main або @latest — це може змінитися і зламати workflow. Фіксуй версії.

3. Запускати все на одному раннері

Якщо workflow робить і білд, і тести, і деплой на одному сервері — помилка в одному кроці скидає все. Розбивай на окремі jobs.

4. Не перевіряти, чи workflow взагалі працює

Створив файл — переконайся, що GitHub його побачив. Вкладка Actions має показувати run. Якщо там пусто — перевір шлях до файлу і синтаксис YAML.

5. Використовувати застарілі образи

ubuntu-latest оновлюється з плином часу, але конкретні версії як ubuntu-20.04 можуть стати недоступними. Перевіряй підтримувані образи на GitHub docs.

Висновок / план дії

GitHub Actions — це найпростіший спосіб додати CI/CD у свій проєкт без окремого сервера. Файл у репозиторії — і все працює.

Що зробити найближчим часом:

Створи .github/workflows/ у своєму репозиторії.
Додай перший workflow з тестами і push у будь-яку гілку.
Перевір вкладку Actions — чи workflow запустився і пройшов.
Додай деплой у staging при створенні pull request.
Збережи секрети в Settings → Secrets — ніколи не хардкодь їх в YAML.

Автоматизація — це не «коли виростемо». Це «з першого дня», і GitHub Actions робить це практично безкоштовно.