NK
и при этом данные отстают на 10 минут?
Size: a a a
2020 January 22
NK
а если новая структура не позволит "положить" данные с прод окружения без конвертаций?
DS
Вот. В этом и проблема.
АБ
Добрый день, коллеги. Подскажите, пожалуйста, как лучше всего организовать стейджинг, когда нельзя допускать чтобы работа тестировщика влияла на процессы в боевой системе, а также в стейджинге нужны максимально актуальные данные (с допустимым запозданием минут в 10)? Кроме того, структура базы данных на стейджинге быть более новая, чем на проде, и может быть даже без обратной совместимости (например, на стейджинге уже применены новые миграции, которые меняют данные, а на проде ещё старая схема БД).
Это накладывает определенные ограничения на процесс разработки. Разработчики не могут делать миграции ломающий данные. И меняется немного способ релизов. Вы сначала релизите функционал изменяющий данные и пишущий его старым и новым способом. Выкатываете это на прод, а потом только дорабатываете фронт и бизнеслогику поверх этих данных
АБ
Но я бы сначала задался вопросом, а оно вам так надо? желание странное какое-то. Может можно без этого процесс построить?
NI
Может проигрывать действия с системой на стейджинг? Но не везде сработает такое
DS
Сейчас думаю об этом.
NK
ну если допустить, что можно хотябы Т-1, то гакагтывать изменения - нормальное решение
NK
а зачем, если не секрет, отставание в 10 минут?
NK
для тестироващиков
NK
это скорее требование к саппорту, чтобы можно было воспроизводить баги
NK
и искать воркэраунды
АБ
Nikita Ilin
Может проигрывать действия с системой на стейджинг? Но не везде сработает такое
В этом случае нужно быть осторожным, если в системе есть отправка уведомлений пользователям или какие-то еще сторонние сайд эффекты.
И если есть генерация случайных паролей, то тоже это нужно отдельно обработать
И если есть генерация случайных паролей, то тоже это нужно отдельно обработать
NI
В этом случае нужно быть осторожным, если в системе есть отправка уведомлений пользователям или какие-то еще сторонние сайд эффекты.
И если есть генерация случайных паролей, то тоже это нужно отдельно обработать
И если есть генерация случайных паролей, то тоже это нужно отдельно обработать
Да, вы всё правильно говорите. Я это и имел в виду. Кейсы аутентификации тоже обрабатывать сложно бывает
АБ
это скорее требование к саппорту, чтобы можно было воспроизводить баги
а почему это нельзя делать на проде?
NK
не всегда возможно - из-за тех же уведомлений и прочего.
DS
а зачем, если не секрет, отставание в 10 минут?
В систему поступают новые данные постоянно. Тестировщику нужно проверить в том числе и работу с новыми данными.
Хм. Сейчас написал, и понял, что новые данные могут поступать по новой механике, и это тоже тестировщику нужно проверить.
Тогда получается, что нужно просто на стейджинг завести тот же поток данных, что и на прод.
Хм. Сейчас написал, и понял, что новые данные могут поступать по новой механике, и это тоже тестировщику нужно проверить.
Тогда получается, что нужно просто на стейджинг завести тот же поток данных, что и на прод.
NK
но вообще- елс естьнормаольное логгирование то и не нужно
DS
Оке. Кажется, проблема решена)
DS
Спасибо!