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