Как CruiseControl.Net может провалить сборку, основанную на изменении метрик?

Question

Хотелось бы, чтобы CruiseControl.Net провалил сборку, когда некоторые метрики кода изменяются в «неправильном» направлении, то есть уменьшается покрытие кода или увеличивается число дефектов жандарма. Метрики Жандарма уже отслеживаются в файле report.xml (поскольку они представлены на графиках веб-панели), покрытие кода сообщается только на странице состояния сборки (и сохраняется в xml отчета о сборке).

Как мне этого добиться?

Answer 1

Что бы вы ни делали, это должно быть частью вашего сценария сборки, а не интеграции проекта CC.Net. Зачем? Поскольку в противном случае разработчики не смогут обнаружить такие сбои сборки до , они передадут код в хранилище. Вы должны стремиться к тому, чтобы один и тот же скрипт сборки выполнялся как на сервере сборки, так и на компьютерах разработчиков. Нет особого смысла в том, чтобы иметь сервер сборки, где половина ваших сборок помечена как неудачная.

Таким образом, вам придется самостоятельно сохранять историю этих статистических данных, а затем сравнивать последние статистические данные с историческими, используя ваш скрипт сборки.

Answer 2

Основной принцип заключается в том, чтобы хранить метрическую оценку и дату где-нибудь (например, в базе данных) и каждый раз сверять метрику с последним сохраненным значением.

Ваша основная проблема - сбор статистики по новой сборке до момента успеха / неудачи - издатели запускаются после того, как сборка уже была успешной / неудачной, поэтому вам нужно будет использовать последовательную задачу для сбора статистики.

Если подумать, я не совсем уверен, что на самом деле не удалась сборка, основанная на метриках, - отличная идея, вы можете обнаружить, что она снова вас укусит.