Задача перед сборкой - удаление рабочей копии в CruiseControl.NET

Question

В настоящее время я нахожусь в процессе настройки среды непрерывной интеграции на работе. Мы используем VisualSVN Server и CrusieControl.NET. Иногда сборка завершается неудачей, и симптомом является то, что в рабочей копии CruiseControl.NET возникают конфликты. Я считаю, что это связано с тем, как я настроил решения Visual Studio. Надеемся, что чем больше проектов мы будем выполнять в этой среде, тем лучше будет наше понимание того, как их настроить, поэтому я не сомневаюсь, почему конфликты происходят на данном этапе. Чтобы исправить сборки, я удаляю рабочую копию и запускаю новую сборку - это работает каждый раз (в настоящее время). Поэтому у меня следующие вопросы: является ли удаление рабочей копии допустимой частью процесса построения непрерывной интеграции и как мне это сделать?

Я пробовал решения, включая MSTask и вызов delete из командной строки, но мне не повезло.

Извините, что так многословен - хорошая работа, это бета:)

Answer 1

Хорошей практикой является полное удаление до или после сборки. Это означает, что у вашей среды сборки нет шансов получить устаревший файл. Ваше здание именно против того, что находится в хранилище.

Удаление рабочей копии возможно, так как я сделал это с Nant.

В Nant у меня был бы чистый скрипт в его собственной папке, кроме того, который я хочу удалить, и затем вызывал бы его из CC.net.

Полагаю, это также возможно при использовании командного файла. Посмотрите на команду rmdir http://www.computerhope.com/rmdirhlp.htm

@ pauldoo

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

Answer 2

Если вы извлекаете jira в CC.NET, для реализации CleanCopy for Subversion будет исправление, которое делает именно то, что вы хотите, и просто устанавливаете CleanCopy равным true внутри вашего блока управления исходным кодом, как с TFS один.

Answer 3

@ jamie: Существует одна причина, по которой вы не сможете выполнять чистую сборку каждый раз при использовании сервера непрерывной интеграции - время сборки. В некоторых проектах, над которыми я работал, чистые сборки занимают более 80 минут (встроенный проект, состоящий из тысяч файлов C ++ для извлечения и последующей компиляции для нескольких целей). В этом случае вы должны сравнить преимущества быстрой обратной связи с вероятностью того, что чистая сборка поймает что-то, чего не сделает добавочная сборка. В нашем случае мы работали над улучшением и распараллеливанием процесса сборки, одновременно допуская инкрементные сборки на нашей машине CI. У нас было несколько проблем, потому что мы не делали чистых сборок, но делая чистую сборку еженедельно или еженедельно, вы могли бы устранить риск, не теряя быструю обратную связь вашей машины CI.

Answer 4

@ Брэд Баркер

Очистить означает просто уничтожить продукты сборки.

Удаление рабочей копии также удаляет все остальное (исходные файлы, файлы проекта и т. Д.).

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

---

@ Jamie

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

Answer 5

Очень распространено и, как правило, хорошей практикой для любого процесса сборки является «очистка» перед выполнением какой-либо существенной сборки. Это предотвращает любые «артефакты» из предыдущих сборок, чтобы испортить вывод.

Чистка - это, по сути, то, что вы делаете, удаляя рабочую копию.