ЕО
Опятьжы, можно всегда написать близкий к реальности генератор нагрузки. Регистрация, выставление ордеров, сработка алертов, это вот всё. Если нада.
+
Size: a a a
2020 February 05
LB
Не надо заводить данные в тестинг с помощью интернал апи, юзай экстернал апи
1. Не все сервисы попаду сразу в новое окружение, но у сервисов есть апи (входящие очереди), туда можно положить что-то сэмулировав непопавшие сервисы . Внешний или не внешний, эмулируем входы на границах нового окружения.
2. Входов этих много, на них надо подавать консистентные (согласованные) данные и ещё правильно выбрать порядок кого первого кормить.
Так вот вопрос, чтоб не писать это все с нуля может есть уже готовые штуки :)
2. Входов этих много, на них надо подавать консистентные (согласованные) данные и ещё правильно выбрать порядок кого первого кормить.
Так вот вопрос, чтоб не писать это все с нуля может есть уже готовые штуки :)
GG
нет
ЕО
1. Старайся не завязываться на готовый X, если у тебя тестовый Y, а X от него зависит. Всегда иди по цепочке зависимостей
2. Не очень понятно, есть ли готовый клиент для твоего приложения? Нет, нету
2. Не очень понятно, есть ли готовый клиент для твоего приложения? Нет, нету
GG
есть проблема
LB
Мы анонимизируем, раскатываем, анонимизируем, открываем разрабам
Прям много сервисов сразу с нуля бутстрапить такими данные умеете?
GG
предположим. что в ордере есть клиент ХХХ и он указан как айди во внешнем сервисе
GG
а потом данные клиента поменялись - что должно быть при просмотре старого ордера ?
GG
или запекать все данные в структуру ордера, которые там могут быть нужны
LB
Ну и да, я сетаки щытаю, что сервис должен быть сам по себе самодостаточен. Есть входные данные, выходные, а всё вовне для тебя не существует. Подавай поток и работай с ним
Редко когда сервис такой pure, что по входу четко считает выход, нафиг он тогда такой нужен
P
Прям много сервисов сразу с нуля бутстрапить такими данные умеете?
Не все, но прям порядошный кусок
LB
1. Старайся не завязываться на готовый X, если у тебя тестовый Y, а X от него зависит. Всегда иди по цепочке зависимостей
2. Не очень понятно, есть ли готовый клиент для твоего приложения? Нет, нету
2. Не очень понятно, есть ли готовый клиент для твоего приложения? Нет, нету
1. У меня не тестовый Y, у меня тестовый X Y Z :) они там друг от друга как то нециклично зависят,но так же зависят от A B C , которые в первую версию тестового окружения не попадут
ЕО
1. У меня не тестовый Y, у меня тестовый X Y Z :) они там друг от друга как то нециклично зависят,но так же зависят от A B C , которые в первую версию тестового окружения не попадут
Ну тестовый контур надо строить от глубоких зависимостей
ЕО
Твои проблемы от того что ты хочешь на две колёсные пары повесить несколько движков :)
LB
1. Старайся не завязываться на готовый X, если у тебя тестовый Y, а X от него зависит. Всегда иди по цепочке зависимостей
2. Не очень понятно, есть ли готовый клиент для твоего приложения? Нет, нету
2. Не очень понятно, есть ли готовый клиент для твоего приложения? Нет, нету
2. Понятно что клиента нет. Вопрос в том как формализовать генерацию входящих запросов, которые наполнят эти сервисы непротиворечивыми данными. Вот пример с валютами и переводами. Как это сделать без человеческого фактора,типа "давайте договоримся что данные должны быть за период 2019 года, список валют A,B,C" в тикете
P
2. Понятно что клиента нет. Вопрос в том как формализовать генерацию входящих запросов, которые наполнят эти сервисы непротиворечивыми данными. Вот пример с валютами и переводами. Как это сделать без человеческого фактора,типа "давайте договоримся что данные должны быть за период 2019 года, список валют A,B,C" в тикете
Именно так, берешь готовое, обезличиваешь, юзаешь