Задача перед сборкой - удаление рабочей копии в CruiseControl.NET
В настоящее время я нахожусь в процессе настройки среды непрерывной интеграции на работе. Мы используем VisualSVN Server и CrusieControl.NET. Иногда сборка завершается неудачей, и симптомом этого является наличие конфликтов в рабочей копии CruiseControl.NET. Я считаю, что это связано с тем, как я настроил решения Visual Studio. Надеемся, что чем больше проектов мы будем выполнять в этой среде, тем лучше будет наше понимание того, как их настроить, поэтому я не сомневаюсь, почему конфликты происходят на данном этапе. Чтобы исправить сборки, я удаляю рабочую копию и запускаю новую сборку - это работает каждый раз (в настоящее время). Итак, мои вопросы: является ли удаление рабочей копии допустимой частью процесса непрерывной интеграции и как я могу это сделать?
Я пробовал решения, включая MSTask и вызов delete из командной строки, но мне не повезло.
Извините за то, что так многословно - хорошая работа, это бета:)
5 ответов
Делать полное удаление до или после сборки - хорошая практика. Это означает, что у вашей среды сборки нет шансов получить устаревший файл. Ваше здание именно против того, что находится в хранилище.
Удаление рабочей копии возможно, так как я сделал это с Nant.
В Nant у меня был бы чистый скрипт в его собственной папке, кроме того, который я хочу удалить, и затем вызывал бы его из CC.net.
Я предполагаю, что это также должно быть возможно с командным файлом. Взгляните на команду rmdir http://www.computerhope.com/rmdirhlp.htm
@pauldoo
Я предпочитаю, чтобы мой CI-сервер делал полное удаление, так как я не хочу удивляться, когда я собираюсь сделать сборку релиза, что всегда должно быть сделано из чистого состояния. Но это должно быть в состоянии справиться с обоими, нет причин, почему нет
Если вы посмотрите на jira CC.NET, то появится патч для реализации CleanCopy для Subversion, который делает именно то, что вы хотите, и просто установите CleanCopy равным true в вашем блоке управления исходным кодом, как и в TFS.
@jamie: Существует одна причина, по которой вы не сможете выполнять чистую сборку каждый раз при использовании сервера непрерывной интеграции - время сборки. В некоторых проектах, над которыми я работал, чистые сборки занимают более 80 минут (встроенный проект, состоящий из тысяч файлов C++ для извлечения и последующей компиляции для нескольких целей). В этом случае вы должны сравнить преимущества быстрой обратной связи с вероятностью того, что чистая сборка поймает что-то, чего не сделает добавочная сборка. В нашем случае мы работали над улучшением и распараллеливанием процесса сборки, одновременно допуская инкрементные сборки на нашей машине CI. У нас было несколько проблем, потому что мы не делали чистых сборок, но делая чистую сборку еженедельно или еженедельно, вы могли бы устранить риск, не теряя быструю обратную связь с вашей машиной CI.
Это очень распространенная и, как правило, хорошая практика для любого процесса сборки сделать "чистую" перед выполнением какой-либо существенной сборки. Это предотвращает любые "артефакты" из предыдущих сборок, чтобы испортить вывод.
Чистка - это то, что вы делаете, удаляя рабочую копию.
@Brad Barker
Очистить означает просто уничтожить строительные продукты.
Удаление рабочей копии также удаляет все остальное (исходные файлы, файлы проекта и т. Д.).
В общем, хорошо, если ваша сборочная машина может работать без полного удаления, поскольку это копирует то, что делает обычный разработчик. Любые конфликты, обнаруженные при обновлении, являются ранним предупреждением о том, чего могут ожидать ваши разработчики.
@jamie
Для официальных релизов да, лучше сделать полностью чистую проверку. Так что я думаю, это зависит от цели сборки.