На самом деле, у нас есть метрики времени деплоя и сложность заключается в другом. Существует много других задач для ускорения процесса деплоя, по которым непрерывно ведётся работа. Сложно понять, что реально повлияло на время в данный момент: плагин или другие активности.
Теперь по поводу графиков. У нас не было цели уменьшить количество прогонов (оно и не уменьшилось, просто раньше прогоны были в других билдах Teamcity, а теперь какая-то их часть перетекла в эту сборку). Цель была в том, чтобы в конкретном прогоне были только нужные тесты. Плагин обеспечивает это, а второй график показывает, что таких прогонов стало относительно много. Первый график лишь демонстрирует, что плагин увеличил популярность сборки, в которой используются Maven-модули для оптимального запуска.
что вокруг автотестов (которые должны помогать) у вас слишком много проблем
А они нам и помогают :) Просто у нас просто очень большой и сложный продукт, на который написано 30000+ автотестов. В итоге сам проект автотестов тоже большой и сложный. Отсюда и столько проблем с его обслуживанием.
зачем вам часто менять базовый код в фреймворке и почему при изменениях есть риск, что автотесты сломаются?
Кажется, что я не совсем понятно в статье выразился. На самом деле, совсем базовый код фреймворка мы меняем редко. Тут скорее проблема в том, что часто меняется наш продукт, и из-за него меняются отдельные куски проекта автотестов, которые могут затрагивать очень много тестов. Например, поменялось описание какого-то базового хэндлера, а он используется в 1000 тестов на разные части продуктов (где-то просто на этапе подготовки данных для теста). Вот для таких ситуаций плагин и используется в большинстве случаев.
И еще было бы круто, если бы был инструмент, который анализирует какие регрессионные тесты нужно запустить исходя из изменений в коде продукта!
Согласен, что это крутая идея. Она у нас обсуждалась в свое время. К сожалению, пока что, цель не оправдывает средства. У нас моно-репозиторий бэкенд проекта, а вот фронтенд распилен на 400+ репозиториев разного размера. Поэтому создать подобный инструмент для анализа не выглядит простой задачей.
Теперь по поводу графиков. У нас не было цели уменьшить количество прогонов (оно и не уменьшилось, просто раньше прогоны были в других билдах Teamcity, а теперь какая-то их часть перетекла в эту сборку). Цель была в том, чтобы в конкретном прогоне были только нужные тесты. Плагин обеспечивает это, а второй график показывает, что таких прогонов стало относительно много. Первый график лишь демонстрирует, что плагин увеличил популярность сборки, в которой используются Maven-модули для оптимального запуска.
Кажется, что я не совсем понятно в статье выразился. На самом деле, совсем базовый код фреймворка мы меняем редко. Тут скорее проблема в том, что часто меняется наш продукт, и из-за него меняются отдельные куски проекта автотестов, которые могут затрагивать очень много тестов. Например, поменялось описание какого-то базового хэндлера, а он используется в 1000 тестов на разные части продуктов (где-то просто на этапе подготовки данных для теста). Вот для таких ситуаций плагин и используется в большинстве случаев.
Согласен, что это крутая идея. Она у нас обсуждалась в свое время. К сожалению, пока что, цель не оправдывает средства. У нас моно-репозиторий бэкенд проекта, а вот фронтенд распилен на 400+ репозиториев разного размера. Поэтому создать подобный инструмент для анализа не выглядит простой задачей.