Сервис назначения ревьюеров для Pull Request’ов

Краткое описание файлов проекта

app основное приложение

migrations — папка с миграциями БД

load-testing — результаты НТ (нагрузочного тестирования)

locustfile.py — скрипт для запуска НТ

Запуск

1. Скачать этот репозиторий с GitHub

git clone https://github.com/Bar1o/pr-avito-project.git
cd pr-avito-project

2. Запустить докер командой

docker-compose up

Чтобы остановить сервис:

docker-compose down

Сервис будет доступен по адресу: http://localhost:8080

Интерактивная документация (Swagger): http://localhost:8080/docs

Миграции базы данных применяются автоматически при старте контейнера.

🛠 Разработка и качество кода

Установка зависимостей

1. Для локальной разработки (вне Docker) установите dev-зависимости:

pip install -r requirements-dev.txt

2. По .env.example создать .env файл и заполнить его.

⚙️ Конфигурация (.env)

Переменная	Описание	Значение по умолчанию
POSTGRES_DB	Имя базы данных	avito_pr_db
POSTGRES_USER	Пользователь БД	postgres
POSTGRES_PASSWORD	Пароль БД	postgres
POSTGRES_HOST	Хост БД (в Docker это имя сервиса)	db
POSTGRES_PORT	Порт БД	5432

Проверка качества кода

Для проверки кода используются Ruff (линтер + форматтер) и Mypy (типизация).

Запуск линтера и форматтера:

ruff check .   # Проверка ошибок
ruff format .  # Автоматическое форматирование

Запуск проверки типов:

mypy . 

Описание решения

Решение реализует требования для тестового задания Avito

Допущения

• /team/add создает/обновляет пользователей: Если изначально была команда из 1 юзера, затем сделали запрос для этой команды с 2 юзерами, то обновляем пользователей в этой команде. Ошибки нет. Далее опять отправляем команду из 1 юзера. Итог: 1 юзер в команде

  Реализую логику удаления прямо внутри метода, использую семантику Full Update (декларативный подход). Считаем, что клиент ожидает, что после выполнения запроса состояние сервера будет в точности соответствовать переданному JSON. Если клиента в JSON нет — значит, его не должно быть и в базе.

  Защита от дубликатов (если участники команды дублируются по ошибке, то сервис не падает, выбирая только уникальные значения)

• alembic для миграций (не сказано, но как без них обойтись — иначе не солидно)

Стек

Python: FastApi, Alembic, SQLalchemy

PostgreSQL

Docker

Структура проекта

.
├── app/
│   ├── api/            # Эндпоинты (ручки) API
│   ├── core/           # Конфигурация и настройки
│   ├── db/             # Подключение к БД
│   ├── models/         # SQLAlchemy модели
│   ├── schemas/        # Pydantic схемы (валидация)
│   ├── services/       # Бизнес-логика
│   └── main.py         # Точка входа
├── migrations/         # Миграции базы данных (Alembic)
├── tests/              # Тесты (если есть)
├── docker-compose.yaml # Оркестрация контейнеров
├── Dockerfile          # Сборка образа
└── requirements.txt    # Зависимости

---

Сервис назначения ревьюеров для Pull Request’ов

Внутри команды требуется единый микросервис, который автоматически назначает ревьюеров на Pull Request’ы (PR), а также позволяет управлять командами и участниками. Взаимодействие происходит исключительно через HTTP API.

Описание задачи

Необходимо реализовать сервис, который назначает ревьюеров на PR из команды автора, позволяет выполнять переназначение ревьюверов и получать список PR’ов, назначенных конкретному пользователю, а также управлять командами и активностью пользователей. После merge PR изменение состава ревьюверов запрещено.

Общие вводные

Пользователь (User) — участник команды с уникальным идентификатором, именем и флагом активности isActive.

Команда (Team) — группа пользователей с уникальным именем.

Pull Request (PR) — сущность с идентификатором, названием, автором, статусом OPEN|MERGEDи списком назначенных ревьюверов (до 2).

1. При создании PR автоматически назначаются до двух активных ревьюверов из команды автора, исключая самого автора.
2. Переназначение заменяет одного ревьювера на случайного активного участника из команды заменяемого ревьювера.
3. После MERGED менять список ревьюверов нельзя.
4. Если доступных кандидатов меньше двух, назначается доступное количество (0/1).

Условия

• Используйте этот API (OpenAPI-спецификация будет предоставлена отдельным файлом — openapi.yaml).
• Объём данных умеренный (до 20 команд и до 200 пользователей), RPS — 5, SLI времени ответа — 300 мс, SLI успешности — 99.9%.
• Пользователь с isActive = false не должен назначаться на ревью.
• Операция merge должна быть идемпотентной — повторный вызов не приводит к ошибке и возвращает актуальное состояние PR.
• Сервис и его зависимости должны подниматься командой docker-compose up. Если решение предусматривает миграции, они также должны применяться при выполнении этой команды. Сервис должен быть доступен на порту 8080.
• Учтите, что соблюдение условий по поднятию сервиса ускорит и упростит проверку вашей работы наставниками.

Дополнительные задания

Эти задания не являются обязательными, но выполнение всех или части из них даст вам преимущество перед другими кандидатами.

• Добавить простой эндпоинт статистики (например, количество назначений по пользователям и/или по PR).
• Провести нагрузочное тестирование полученного решения и приложить краткие результаты тестирования к решению.
• Добавить метод массовой деактивации пользователей команды и безопасную переназначаемость открытых PR (стремиться уложиться в 100 мс для средних объёмов данных).
• Реализовать интеграционное или E2E-тестирование.
• Описать конфигурацию линтера.

Требования по стеку

Язык сервиса: предпочтительным будет Go, при этом вы можете выбрать любой, удобный вам.

База данных: предпочтительной будет PostgreSQL, при этом вы можете выбрать любую, удобную вам (допускается in-memory реализация).

Ход решения

Если у вас возникнут вопросы по заданию, ответы на которые вы не найдёте в описанных «Условиях», вы вольны принимать решения самостоятельно.
В таком случае приложите к проекту README-файл, в котором будет список вопросов и пояснения о том, какие допущения вы сделали и почему именно выбранным вами способом.

Оформление решения

Необходимо предоставить публичный git-репозиторий на любом публичном хосте (GitHub / GitLab / etc), содержащий в master/main ветке:

1. Код сервиса
2. Makefile c командами сборки проекта / Описанная в README.md инструкция по запуску
3. Описанные в README.md вопросы/проблемы, с которыми столкнулись, и ваша логика их решений (если требуется)