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

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

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

Извините за многословность - молодец, это бета :)

Ответов (5)

Решение

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

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

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

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

@pauldoo

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

@ Брэд Баркер

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

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

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


@jamie

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

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

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

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

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