Задача предварительной сборки - удаление рабочей копии в CruiseControl.NET
https://stackoverflow.com/questions/8127
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
В настоящее время я нахожусь в процессе настройки среды непрерывной интеграции на работе.Мы используем сервер VisualSVN и CrusieControl.NET .Иногда сборка завершается неудачно, и симптомом является наличие конфликтов в CruiseControl.ЧИСТАЯ рабочая копия.Я полагаю, это связано с тем, как я настроил решения Visual Studio.Надеюсь, чем больше проектов мы запустим в этой среде, тем лучше мы будем понимать, как их настроить, поэтому я не задаюсь вопросом, почему конфликты возникают на данном этапе.Чтобы исправить сборки, я удаляю рабочую копию и запускаю новую сборку - это работает каждый раз (в настоящее время).Итак, мои вопросы таковы:является ли удаление рабочей копии допустимой частью процесса сборки непрерывной интеграции, и как мне это сделать?
Я пробовал решения, включая MSTask и вызов delete из командной строки, но мне не везет.
Извините за многословие - хорошая работа, это бета-версия :)
Решение
Выполнение полного удаления до или после сборки является хорошей практикой.Это означает, что нет никаких шансов, что ваша среда сборки обнаружит устаревший файл.Ваше построение в точности соответствует тому, что есть в репозитории.
Удаление рабочей копии возможно, так как я сделал это с помощью Nant.
В Nant у меня был бы чистый скрипт в его собственной папке, отличной от той, которую я хочу удалить, и затем я бы вызвал его из CC.net.
Я предполагаю, что это также должно быть возможно с помощью пакетного файла.Взгляните на команду rmdir http://www.computerhope.com/rmdirhlp.htm
@pauldoo
Я предпочитаю, чтобы мой сервер CI выполнял полное удаление, так как я не хочу никаких сюрпризов, когда я перейду к сборке релиза, которая всегда должна выполняться из чистого состояния.Но он должен быть способен справиться и с тем, и с другим, без каких-либо причин, почему бы и нет
Другие советы
@джейми:Существует одна из причин, по которой вы, возможно, не сможете выполнять чистую сборку каждый раз при использовании сервера непрерывной интеграции - время сборки.В некоторых проектах, над которыми я работал, чистые сборки занимают более 80 минут (встроенный проект, состоящий из тысяч файлов C ++ для проверки, а затем компиляции для нескольких целевых объектов).В этом случае вы должны взвесить преимущество быстрой обратной связи с вероятностью того, что чистая сборка поймает что-то, чего не поймает инкрементная сборка.В нашем случае мы работали над улучшением и распараллеливанием процесса сборки, в то же время разрешая инкрементные сборки на нашей машине CI.У нас действительно было несколько проблем, потому что мы не выполняли чистые сборки, но, выполняя чистую сборку каждый вечер или еженедельно, вы могли бы устранить риск, не теряя быстрой обратной связи с вашей CI-машиной.
Если вы проверите CC.NET's джира установлен патч для реализации CleanCopy для Subversion, который делает именно то, что вы хотите, и просто устанавливает CleanCopy равным true внутри вашего блока управления версиями, как и в случае с TFS.
Это очень распространенная и, как правило, хорошая практика для любого процесса сборки - выполнять "чистку" перед выполнением какой-либо значительной сборки.Это предотвращает появление любых "артефактов" из предыдущих сборок, которые могли бы испортить результат.
Очистка - это, по сути, то, что вы делаете, удаляя рабочую копию.
@Брэд Баркер
Очистить - значит просто стереть с лица земли продукты сборки.
Удаление рабочей копии также удаляет все остальное (исходные файлы и файлы проекта и т.д.).
В общем, приятно, если ваша машина сборки может работать без полного удаления, так как это повторяет то, что делает обычный разработчик.Любые конфликты, которые он обнаруживает во время обновления, являются ранним предупреждением о том, чего могут ожидать ваши разработчики.
@джейми
Для официальных релизов да, лучше сделать полностью чистую проверку.Так что я думаю, это зависит от цели сборки.
