Мы достигли # 1 с ccnet, создавая cc-проект для каждого необходимого значения определенного «параметра».
Мы начали с инкрементной сборки и полной сборки в ccnet.
Инкрементная сборка обновила рабочую копию, собрала ее, запустила частичный набор тестов и отправила результаты по электронной почте.
Полная сборка обновила другую рабочую копию, перестроила решение, запустила все юнит-тесты, сгенерировала установщики, экспортировала установщики в определенные места и, наконец, запустила регрессионные тесты на других назначенных тестовых машинах.
Полная сборка сделала много вещей, и иногда мы хотели только пересобрать код и сгенерировать установщики.Мы хотели избежать запуска юнит-тестов и порождать регрессионные тесты.
Поэтому мы добавили еще один проект cc под названием fullbuild_notest.Это выполняет те же цели nant, что и полная сборка, за исключением того, что пропускает часть тестирования.У нас есть файл сборки nant, который является своего рода загрузчиком с точками входа.Вначале мы устанавливаем для свойства с именем «fullbuild-testing-enabled» значение true или false, а затем вызываем дочернюю цель для фактического построения.Дочерняя цель и ее дочерние элементы проверяют флаг «fullbuild-testing-enabled», чтобы определить, стоит ли проводить тестирование.
В некотором смысле это хорошо, потому что дает пользователям панели мониторинга определенный набор вариантов.И в некотором смысле это громоздко, потому что каждый раз, когда требуется новый параметр или значение параметра, требуется изменение кода nant / ccnet.