Автоматическая проверка и сборка для пет-проекта

Что это простыми словами

Робот, который при каждом изменении в репозитории запускает ваши тесты и проверки. Прошло — рядом с изменением зелёная галочка. Не прошло — вы узнаёте об этом сразу, а не через неделю.

Английское сокращение прижилось, но по-русски это просто автоматическая проверка изменений.

Зачем в маленьком проекте

Ловит забытое. Классика: у вас всё работает, потому что на машине стоит библиотека, которую вы забыли внести в список зависимостей. У всех остальных проект не запускается. Автоматическая сборка на чистой машине ловит это сразу.

Дисциплинирует. Красная отметка рядом с изменением неприятна, и тесты начинают чиниться, а не копиться.

Хорошо смотрится. Зелёная отметка в репозитории — сигнал работодателю, что человек знает про автоматизацию. Это редкость в учебных проектах.

Как устроено

Кладёте файл описания в определённую папку репозитория. В нём указываете: когда запускать, на чём и что делать.

Файл для проекта на Python:

name: checks

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: ruff check .
      - run: pytest

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

Всё. Никакой настройки серверов — площадка даёт машину сама.

Что стоит проверять

Тесты. Основное.

Стиль и очевидные ошибки. Проверка кода анализатором ловит неиспользуемые переменные, опечатки в именах и подобное.

Сборку. Для фронтенда: собирается ли проект вообще.

Форматирование. Если договорились о едином стиле — пусть робот следит, а не люди в обсуждениях.

Чего не делать на старте

Не настраивайте автоматическую выкладку сразу. Сначала проверки, потом уже выкладка. Иначе сломанный код поедет на сервер автоматически.

Не усложняйте. Один файл, три шага. Матрицы версий, кэширование и параллельные задачи — потом, когда появится реальная нужда.

Не проверяйте по расписанию то, что можно проверять при изменениях.

Частые проблемы

Работает у меня, падает в сборке. Почти всегда — забытая зависимость или файл, не попавший в репозиторий. Это и есть главная польза: узнать об этом до того, как проект откроет кто-то другой.

Тесты требуют базу. Площадки умеют поднимать вспомогательные службы рядом с задачей — это описывается в том же файле.

Нужны секретные ключи. Их хранят в настройках репозитория и подставляют как переменные окружения. В файл описания класть нельзя ни в коем случае.

Долгая сборка. Если каждый прогон занимает десять минут, вы перестанете ждать. Кэшируйте установку зависимостей.

Сколько это занимает

Настроить в первый раз — полчаса-час с чтением документации. Дальше файл переносится из проекта в проект почти без изменений.

Отдача несоразмерно больше: вы перестаёте выкладывать сломанное и приучаетесь держать тесты в рабочем состоянии.