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

Question

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

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

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

Answer 1

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

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

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

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

@pauldoo

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

Answer 2

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

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

Answer 3

Баркер @ Брэд

Чистые средства просто вытереть сборки продукции.

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

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

---

@jamie

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

Answer 4

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

Answer 5

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