98 lines
5.6 KiB
Markdown
98 lines
5.6 KiB
Markdown
# ⚠️ LEGACY — НЕАКТУАЛЬНО. Исторический документ.
|
|
|
|
# Задание: архитектура приложения автотестов 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 пайплайны
|