Здравствуйте, спасибо за обратную связь, попробуйте заиспользовать в вашем проекте эту идею, возможно по ходу что-то еще улучшите или добавите, ну и если будет еще обратная связь- you're welcome!
Про балансировку тестов у нас была похожая идея, но мы решили проблему долгих тестов иначе - вынесли их в отдельную категорию и фильтруем их при обычном запуске тестов. На наш взгляд это решение имеет смысл когда длинных тестов не много, у нас их в районе 100. На деплое они запускаются отдельно, т.е. функционал этих тестов мы проверяем просто реже.Что касается оптимизаций запуска тестов у нас есть несколько идей:
Здравствуйте , у нас есть спредшит с расписанием дежурств по деплою + отпуска у ребят, оттуда и берет, но при желании можно заинтегрировать с чем угодно.
Здравствуйте, спасибо за ваш комментарий, хотел добавить:
Ретраи - вершина айсберга процесса работы с флаки тестами и больше про лечение симптомов проблем, которые мы решаем под капотом с одной стороны и с другой- для некоторых бизнес процессов существуют жесткие временные ограничения по прогону тестов и разбору рез-ов, в 99% случаев флаки возникает по причине инфра проблем и нет смысла тратить время на ручные/автоматические проверки сейчас, когда проблему можно решить ретраем, в стату положить кейс и в спокойном режиме с ним разобраться после;
Под капотом также занимаемся стабилизацией тестов, в начале это были ручное заведение задач на стабилизацию, позже авто, сейчас сервисы автомьютов-авторазмьютов/карантинов;
Постоянная работа с причесыванием/улучшением кода/фреймворка тестов;
Мы периодически делимся опытом в сообществе, здесь сможете найти более детальную информацию про нашу работу в контексте повышения стабильности тестов:
Здравствуйте, спасибо за ваш комментарий, хотел добавить, что у нас есть проекты, где используется механизм code owners (об этом можно почитать тут: https://habr.com/ru/company/wrike/blog/532508/) для разметки кода и статический анализатор. Это позволяет назначать ревьюеров из списка ответственных за код, и такой подход также реализован в JiGit. Однако, во многих проектах это не работает по ряду причин:
Разметки code owners не было, а заводить и поддерживать её дорого.
В QAA команде принято cross-ревью. Любой инженер из команды может ревьюить любую часть кода (с учетом его экспертизы и капасити).
code owners не просто сынтегрировать с календарем, а учитывать отпуска и тд необходимо для ускорения ревью.
здравствуйте, спасибо за вопрос, исполнитель берется из списка ревьюверов, в нашем случае назначать список людей на ревью мерж реквеста выглядит как еще дополнительная проблема- асайнерам нужно как-то договариваться между собой, кто возьмет на ревью и тд и потенциально могут возникать дополнительные коллизии("а я думал, ты возьмешь/ты же вроде собирался поревьювить/я в отпуске, давай ты...") , другими словами решали проблему человеческого фактора между автором кода и ревьювером, а, добавляя список ревьюверов, придется еще решать проблему человеческого фактора между ревьюверами, одна проблема vs две проблемы и еще добавил бы , что не хотелось размывать ответственность за ревью между ревьюверами из списка.
Здравствуйте, спасибо за обратную связь, попробуйте заиспользовать в вашем проекте эту идею, возможно по ходу что-то еще улучшите или добавите, ну и если будет еще обратная связь- you're welcome!
Про балансировку тестов у нас была похожая идея, но мы решили проблему долгих тестов иначе - вынесли их в отдельную категорию и фильтруем их при обычном запуске тестов. На наш взгляд это решение имеет смысл когда длинных тестов не много, у нас их в районе 100. На деплое они запускаются отдельно, т.е. функционал этих тестов мы проверяем просто реже.Что касается оптимизаций запуска тестов у нас есть несколько идей:
Maven Modules Merger - позволяет оптимизировать запуск тестов в многомодульном проекте мавен https://habr.com/ru/company/wrike/blog/703986/
Параллельные ретраи - статья должны выйти в ближайшем будущем.
Надеемся данный материал будет Вам полезен!Спасибо!
Здравствуйте , у нас есть спредшит с расписанием дежурств по деплою + отпуска у ребят, оттуда и берет, но при желании можно заинтегрировать с чем угодно.
Здравствуйте, спасибо за ваш комментарий, хотел добавить:
Ретраи - вершина айсберга процесса работы с флаки тестами и больше про лечение симптомов проблем, которые мы решаем под капотом с одной стороны и с другой- для некоторых бизнес процессов существуют жесткие временные ограничения по прогону тестов и разбору рез-ов, в 99% случаев флаки возникает по причине инфра проблем и нет смысла тратить время на ручные/автоматические проверки сейчас, когда проблему можно решить ретраем, в стату положить кейс и в спокойном режиме с ним разобраться после;
Под капотом также занимаемся стабилизацией тестов, в начале это были ручное заведение задач на стабилизацию, позже авто, сейчас сервисы автомьютов-авторазмьютов/карантинов;
Постоянная работа с причесыванием/улучшением кода/фреймворка тестов;
Мы периодически делимся опытом в сообществе, здесь сможете найти более детальную информацию про нашу работу в контексте повышения стабильности тестов:
https://habr.com/ru/company/wrike/blog/588873/
https://habr.com/ru/company/wrike/blog/574320/
https://youtu.be/kubqCb_7cxc
Здравствуйте, спасибо за ваш комментарий, хотел добавить, что у нас есть проекты, где используется механизм code owners (об этом можно почитать тут: https://habr.com/ru/company/wrike/blog/532508/) для разметки кода и статический анализатор. Это позволяет назначать ревьюеров из списка ответственных за код, и такой подход также реализован в JiGit. Однако, во многих проектах это не работает по ряду причин:
Разметки code owners не было, а заводить и поддерживать её дорого.
В QAA команде принято cross-ревью. Любой инженер из команды может ревьюить любую часть кода (с учетом его экспертизы и капасити).
code owners не просто сынтегрировать с календарем, а учитывать отпуска и тд необходимо для ускорения ревью.
Здравствуйте, спасибо за вопрос, данные собираем в бд(postgres), визуализируем через графану.
здравствуйте, спасибо за вопрос, исполнитель берется из списка ревьюверов, в нашем случае назначать список людей на ревью мерж реквеста выглядит как еще дополнительная проблема- асайнерам нужно как-то договариваться между собой, кто возьмет на ревью и тд и потенциально могут возникать дополнительные коллизии("а я думал, ты возьмешь/ты же вроде собирался поревьювить/я в отпуске, давай ты...") , другими словами решали проблему человеческого фактора между автором кода и ревьювером, а, добавляя список ревьюверов, придется еще решать проблему человеческого фактора между ревьюверами, одна проблема vs две проблемы и еще добавил бы , что не хотелось размывать ответственность за ревью между ревьюверами из списка.