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

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

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

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

CleanCopy для Subversion теперь реализован в версии 1.4.1. Вы просто должны установить CleanCopy на true в вашей конфигурации
Alex 19.11.2008 18:55:37
5 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

@pauldoo

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

10
11.08.2008 20:42:24

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

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

0
11.08.2008 20:16:01

@Brad Barker

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

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

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


@jamie

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

0
12.08.2008 08:47:12

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

2
25.08.2008 12:01:25

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

2
23.10.2008 20:39:03