Files
autotest/DOCS/architecture-questions-for-sonnet.md
T

96 lines
5.5 KiB
Markdown

# Задание: архитектура приложения автотестов Nubes
## Контекст
Проект: автотесты операций сервисов облачной платформы Nubes.
Обсуждение с заказчиком: `/home/naeel/nubes/autotest/DOCS/dialogues.md`
### Что есть сейчас
1. **Flask-приложение** в `site/app.py` (задеплоено на Nubes как pythonk8s):
- Токен-вход (cookie)
- Показывает организацию пользователя
- Список всех инстансов пользователя
- Таблица сервисов с раскрытием операций (AJAX)
- Дизайн Nubes (CSS custom properties, Lucide-иконки, карточки)
2. **API облака** (три стенда: dev/test/prod):
- `GET /services` — список сервисов
- `GET /services/{id}` — детали + операции
- `GET /instanceOperations/default/{opId}` — параметры операции (valueList, dataDescriptor, isModifiable)
- `GET /instances` — инстансы пользователя
- `POST /instances` — создать инстанс
- `POST /instanceOperations` — запустить операцию
- Аутентификация: `Authorization: Bearer <TOKEN>`
- Обязательный `User-Agent: Mozilla/5.0`
3. **YAML-конфигурации сервисов** в `/home/naeel/nubes/autotest/STANDS/` — полные описания всех сервисов и их параметров (по стендам).
### Что требуется (из диалога с Сергеем Мищуком)
- Веб-интерфейс со списком сервисов-операций и статусами тестирования
- Конфигурирование тестов (НЕ кодировать)
- Возможность выбирать какие операции тестировать для каждого сервиса
- **Запуск прямо на платформе**
- Не все операции можно делать (например, организацию создавать нельзя)
- Для многих сервисов — удаление с передержкой (создать можно, удалить нельзя)
- Объекты создавать и удалять в специальной тестовой организации
- Пока со своим токеном, потом — токенами по стендам
## Вопросы для архитектурного решения
### 1. Модель данных / конфигурация тестов
Как хранить конфигурацию тестов? Нужна ли БД?
- Какие сущности: TestSuite (набор тестов), TestCase (один тест = сервис + операция), TestRun (прогон)?
- Как конфигурировать какие операции тестировать, а какие нет?
- Как задавать параметры для операций (значения полей)?
- Нужна ли привязка к конкретной организации (для isolate-тестов)?
### 2. Процесс тестирования (Pipeline)
Какая механика запуска и отслеживания:
- Пользователь выбирает сервисы/операции → нажимает «Запустить»
- Что происходит дальше? Последовательно? Параллельно?
- Как отслеживать статус каждой операции?
- Как обрабатывать долгие операции (удаление с передержкой)?
- Нужен ли откат (удалить созданное после теста)?
### 3. UI/UX
- Как должен выглядеть экран конфигурации тестов?
- Нужен ли конструктор pipeline (drag-and-drop операций)?
- Как показывать результаты: таблица? дерево? график?
- История прогонов?
### 4. Техническая архитектура
- Flask-бэкенд остаётся или что-то другое?
- Нужна ли очередь (Redis, RabbitMQ) для запуска тестов?
- Поллинг или WebSocket для статуса?
- Где хранить состояние: SQLite? PostgreSQL? Файлы?
### 5. Multi-stand
- Один инстанс приложения на все стенды или по одному на стенд?
- Как переключаться между dev/test/prod?
- Разные токены для разных стендов?
## Ограничения
- Приложение деплоится как pythonk8s на Nubes (Flask, gunicorn)
- Структура: `site/app.py` + модули в `site/`
- Импорты без префикса `site.` (папка `site/` — не пакет, конфликт со stdlib)
- `if __name__ == "__main__": app.run(host="0.0.0.0", port=5000)` — обязательно
- Минимум зависимостей (Flask, gunicorn, requests — уже есть)
- Дизайн Nubes (CSS custom properties, карточки, Lucide)
## Что НЕ нужно
- Авторизация пользователей (пока один технический токен)
- Мобильная версия
- Сложная админка
- CI/CD пайплайны