8.6 KiB

Raw Blame History

Перенос тестирования на кабинет HR — простым языком

Это короткий проектный документ для заказчика и команды: зачем две базы, как они «сходятся» по людям, что делаем по шагам. Технические детали, таблицы и спринты — в отдельном файле: migration-to-tgflaskform.md.

1. В чём суть

Сейчас модуль тестирования может жить так:

Старое приложение (то, что уже есть): своя программа и своя база clinic_tests. В ней заведены «пользователи модуля» (логин, пароль и т.д.) и все тесты, попытки, ответы.
Целевое место — общий HR-кабинет на Python (tgFlaskForm): там уже есть раздел тестирования, данные лежат в другой базе — hr_bot_test, и каждый человек привязан к карточке сотрудника в HR (staff_members).

Перенос — это не «скопировать файлы», а аккуратно переложить смысл из одной базы в другую так, чтобы в HR было понятно: этот тест написал тот же Иванов, эту попытку прошла та же Петрова, и чтобы баллы и история не потерялись.

На переходный период можно держать новый экран на Flask отдельно (папка flask_app в этом репозитории) — тот же подход, что в кабинете, но свой адрес в браузере, пока не готовы полностью перейти на один вход.

2. Две базы — зачем и как они связаны

База	Простыми словами
`clinic_tests`	«Песочница» модуля тестирования: здесь живут тесты, версии, попытки в том виде, в каком их делало старое приложение.
`hr_bot_test`	«Общий дом» HR: сотрудники, отделы, права, и при переносе — те же тесты, но уже в таблицах вида `testing_*`, привязанные к сотрудникам.

Обе базы обычно стоят на одном сервере PostgreSQL, но это разные логические хранилища (как два разных диска с разными папками). Скрипт переноса подключается к обеим и переписывает данные из одной в другую по правилам (сначала тесты и вопросы, потом попытки и ответы — чтобы ничего не «повисло» без ссылки).

3. Связка «пользователь модуля» ↔ «сотрудник в HR»

В clinic_tests человек заведён как запись в таблице users (логин, роль в модуле и т.д.).

В hr_bot_test человек — это staff_members (та самая карточка из кадрового контура).

Чтобы перенос сработал, для каждого, кто важен для истории (автор теста, кто проходил, кто назначал), нужно знать одно число: идентификатор сотрудника в HR — staff_members.id.

На практике это делается так:

В таблице users (в clinic_tests) есть поле staff_id — туда записывается как раз staff_members.id из HR. Тогда программа понимает: логин ivanov в модуле тестов = сотрудник № 12345 в HR.
Если staff_id пустой — автоматом не понять, кто это. Тогда до переноса нужно вручную или полуавтоматом составить соответствия: например таблица «логин / email / ФИО → номер сотрудника в HR», заполнить staff_id или отдать это скрипту миграции отдельным файлом.

Имеется в виду не «настроить взаимодействие двух баз в реальном времени» (как два приложения, которые постоянно синхронизируются), а один раз правильно сопоставить людей, чтобы при копировании данных в HR не оказалось «логин есть, а сотрудник не найден».

4. Что делаем по этапам (без жаргона)

Подготовка

Решить: пока живём на старой базе в новом Flask или сразу пишем в HR-базу — и не вести параллельно «два источника правды» без правил.
Список сценариев: создание теста, версии, назначение, прохождение, разбор, отчёты — и отметить, что уже есть в кабинете, чего не хватает.

Данные

Проверить staff_id у нужных users.
Сделать резервную копию обеих баз.
Запустить скрипт в режиме «только посмотреть» (--dry-run): он ничего не пишет в HR, только показывает, сколько чего нашёл.
На копии HR-базы один раз прогнать настоящий перенос, открыть несколько тестов и попыток глазами.
В согласованное короткое окно (когда никто не правит тесты) — перенос на боевую HR-базу, проверка, смена ссылок для пользователей на кабинет.

После переноса

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

Подробные шаги ETL, порядок таблиц и ограничения текущего скрипта — в migration-to-tgflaskform.md, раздел 4. Скрипт: в монорепозитории HR, файл HR_TG_Bot/tgFlaskForm/tools/migrate_clinic_tests_to_hr.py.

5. Что может пойти не так

Не все люди сопоставлены с HR — часть тестов или попыток не перенесётся или перенесётся с ошибками. Лечится заранее: отчёт по пустым staff_id и дозаполнение.
Два места, куда одновременно пишут — данные разъедутся. Лечится правилом: в период перехода пишем только в одно место (или второе только для пилота).
Назначения «на весь отдел» в старой базе — в HR их нужно либо развернуть в список конкретных сотрудников на дату переноса, либо доработать логику отдельно — это заранее обсуждается с заказчиком.

6. Куда смотреть дальше

Нужно	Файл
Технический план, спринты, таблицы	migration-to-tgflaskform.md
Состояние кода старого приложения	PROJECT_STATUS.md
Запуск нового Flask-контура в Docker	../flask_app/README.md
Установка и базы в целом	../README.md

8.6 KiB Raw Blame History