Участие в разработке Umbryx¶
Предварительные требования¶
- Docker + Docker Compose v2
- Python 3.11+ (для разработки бэкенда вне контейнеров)
- Node.js 20+ (для разработки фронта вне контейнеров)
- Git
Локальная настройка¶
- Скопируйте файл окружения и при необходимости поправьте значения:
- Соберите и запустите весь стек:
- Приложение будет доступно на
http://localhost:3000(nginx-прокси). При первом запуске мастер настройки создаёт стартовый аккаунт админа.
Процесс разработки¶
Вся разработка функциональности следует модели ветвления: ветки функциональности вливаются в
dev, а dev вливается в main вручную после валидации.
Коротко:
- Создайте ветку от
dev:
-
Внесите изменения.
-
Провалидируйте полной пересборкой контейнеров:
- Прогоните линтер бэкенда:
- Прогоните линт и сборку фронта:
-
Если возможность видна пользователю — задокументируйте её в журнале разработки (в приватном репозитории).
-
Влейте в
dev:
Конвенции кода¶
Бэкенд (Python)¶
- Форматтер: black (длина строки 100)
- Линтер: ruff
- Конфиг:
backend/pyproject.toml - Ошибки: используйте
AppErrorизcore/errors.pyв новых эндпоинтах - Логирование:
get_logger(__name__)изcore/logging_setup.py; без голыхprint() - Енамы: типы из
core/enums.pyдля ролей и severity; без магических строк
Фронтенд (JavaScript/JSX)¶
- Линтер: eslint (flat config в
frontend/eslint.config.js) - Запуск:
npm run lint - Без голых
console.logв коде для промышленной эксплуатации (console.warnиconsole.errorразрешены) - Хуки доменных данных:
src/hooks/useProjectData.jsвместо прямых вызововapi.*в компонентах при стандартной выборке списков
Pre-commit хуки (опционально)¶
Установите pre-commit, чтобы проверки выполнялись автоматически перед каждым коммитом:
Конфиг: .pre-commit-config.yaml в корне репо.
Миграции базы данных¶
Изменения схемы обязаны оформляться Alembic-миграцией. Никогда не меняйте схему вручную и не правьте существующие миграции.
Добавление миграции¶
cd backend
# 1. Отредактируйте app/models/<domain>.py — добавьте колонку/таблицу в ORM-класс
# 2. Сгенерируйте миграцию (autogenerate сравнивает модели с живой БД):
make db-new MSG="add last_login_at to users"
# 3. Просмотрите файл в alembic/versions/ и проверьте корректность
# и upgrade(), и downgrade()
# 4. Примените локально для подтверждения:
make db-upgrade
Стайлгайд миграций¶
- Используйте
op.add_column(),op.create_table(),op.drop_column()и т.п. (операции Alembic), а не сыройop.execute(text(...))для структурных изменений. - Всегда реализуйте
downgrade(). Для необратимых миграций данных добавьте комментарий, почему откат невозможен, и бросайтеNotImplementedError— чтобы падало с явной ошибкой. - Одна миграция — одно логическое изменение.
- Тестируйте оба направления:
make db-upgrade, затемmake db-downgrade, затем сноваmake db-upgrade.
Основные make-цели (из backend/)¶
| Команда | Действие |
|---|---|
make db-status |
Текущая версия миграций |
make db-upgrade |
Применить все ожидающие миграции |
make db-downgrade |
Откатить на один шаг |
make db-new MSG="..." |
Сгенерировать миграцию из изменений моделей |
make db-history |
Полная цепочка миграций |
Тесты¶
Тесты бэкенда лежат в backend/tests/. Запуск внутри контейнера:
Со свежей изолированной БД (рекомендуется для CI):
Или через выделенный тестовый образ (SQLite, внешние сервисы не нужны):