Pull to refresh
58
0
Andrey Radoselskiy @Anrad

Software Architect

Send message
спасибо. а я правильно понял — вы просто заменяете старые скрипты (даги) на новые в целевой папке при деплое. А аирфлоу при каждом запуске дага считывает его (скрипт) заново? Если да, то бывали ли моменты когда воркер хотел забрать папку в момент когда в ней все было удалено?
Добрый день. Спасибо. Впервые читаю про аирфлоу. Щчень полезная статья.
Подскажите плис, можно ли в аирфлоу «даги» обновлять на лету как CI\CD? Как пример — разработчик обновил код Дага в гите и… опс… аирфлоу имеет у себя новую версию Дага. Это возможно?
Yes. Of course. I agree. But in case of nobody want to document it and nobody ready to change, in my view, the best option to use network monitoring or a distribute trace capability like Spring Cloud Sleuth.
В конкретном, выше описанном случае, разбиение сервисов на группы не практикуется.
Зависимости пока решили не документировать. Рассматривали две опции. 1) Описывать в том же Readme.md отдельной секцией. 2) Контролировать зависимости автоматически через мониторинг сетевой активности и авто репортинг с размещением в отдельный репозиторий для контроля изменений. И для Кубернета и для OpenShift есть такие средства. Я более склоняюсь к авто контролю зависимостей.
Полностью согласен. И в конкретном случае все внешние API все же идут через солюшин архитектора. Но код-вперед активно используется для рестов фронтенда (а у нас все фулстеки) и для бэкенд микросервисов, которые никто особенно не согласуют. И представленное решение является попыткой наведения хоть какого-то порядка
и это правильно ведь основная идея это использовать максимум возможностей в специфицировании от кода
Согласен -) Я с явой и работаю. Идея в том что надо в таком подходе использовать имеющиеся инструменты аннотации кода по максимуму.
I can not just open a page because there is js that should be executed.
By the way, overall, we decided to use selenium pretest step to collect all needed tokens.
Because it works very well and could be easily maintenance of juniors.
А как? Куда в доку посмотреть? Я не увидел такого в его админке. Если их можно через его API нагенерировать, то можно это легко автоматизировать.
Да конечно была такая идея. Пока нереализуема организационно.
Узнаю архитектурный подход -))) Задача вполне прямая. Нагрузить систему целиком со всеми компонентами. Системное тестирование, не компонентное. И мудрим мы потому что прямая эмуляция пользовательской нагрузки через браузеры и стоит дохера, и в амазоне арендовать сервера на часок не дают.

Но это неважно. Вижу вы архитектор. Вот вы как бы организовали решение? Ну или задачу выпрямили? Мне бы вот подсказку как любым другим способом токены получить!

зы. Дык Селениум в нагрузочном тестировании счас не участвует. Он известным мне способом получает токены. Стабильно, дешево и надежно. И любые другие способы я вот и ищу.
там написано нагрузочные тесты. но это в данном случае не важно.
Да, согласен. Выглядит как не такой уж простой путь по затратам. Умышленно пока его избегал. Надеялся что все уже давно порешали -)
его скрипт использует grant_type=password, у меня нет возможности включить этот грант. Также подозреваю что это не сработает так как у нас brokering на другой авторизационный сервер. Но идея понятная. Попробую
Да Сергей. Именно так мы и видели ситуацию неделю назад.
Если под клиентом понимать js исполняемый в браузере, то, согласен, без проблем. Можете подсказать где в JMeter есть клиент в котором можно реализовать? Тут в качестве клиента используется selenium.
Согласен. Но у нас используется brokering и логин/пароль вводится на странице другого сервиса, который нам не разрешили изменить. Keycloak ничего о паролях не знает. Включение password autorization grant ничего не даст. Я так вижу ситуацию счас.
1) да, эффект есть, но реальные цифры под NDA. Давайте попробуем подсчитать абстрактно (данные условные) — 1000 тестов (обязательный регресс) проходят за (условно) 3 часа в 50 потоков = 3х50 = 150 часов чистого времени х 10 фиксов на релиз = 1500 часов. И я бы еще умножил на минимум 3 так как человек вводит данные медленнее чем робот. но не будем. Получаем — каждый релиз мы экономим 1500 часов ручного тестирования. Или 150 часов на каждый апдейт выходящий в продуктив.
ИМХО. Важнее тут не только экономия, а то что за 3 часа вы никакими реальными силами не пройдете 1000 тестов по всей системе.Это была главная конечно цель.
2) сейчас в жире 5700 задач = 171 баг
3) на первых этапах результат автотеста надо было воспроизвести обязательно руками для заведения база на разработку. Сейчас доверия поболее. Мы выстраивали эту работу.
Функционалы конечно. каждый занимается своей работой… и ИМХО мы все не занимаемся самым проблемным местом. Самое проблемное место это — продажа заказчику -)
Коллеги, все вы задаете правильные вопросы -) Понимаю, что без кода некоторые аспекты выглядят непонятно. У меня уже написана третья часть в которой приведены шаблоны классов BaseTest класс с RuleChain, Test класс и Action класс. И я рассчитываю что ее опубликуют до нового года. И некоторые вещи станут понятнее -)
сколько ошибок по вине тестового кода на 100 запусков тестов — статистика по жире показывает счас что только около 3% всех задач имеют тип «баг». Это значит что причиной падения теста была либо системная ошибка (у нас это все рантайм эксепшины), или было найдено несоответствие в реализации теста. Если я вас правильно понял -)
1

Information

Rating
Does not participate
Location
Wien, Wien, Австрия
Date of birth
Registered
Activity