Там нет никаких реальных недостатков, за исключением того, что с CI сервер будет занят.
Причина этих сборок являются:
NB: Каждого утра у вас есть инсталлятор полностью построен выпуск, который вы можете проверить. Вы знаете все свои сборки кода, и каждый день у вас есть готовая версия, которую вы могли бы отправить, если хотите. Это намного лучше, чем программист тратит день на создание документа «Как создать выпуск» шаг за шагом, чтобы создать установщик каждый раз, когда вы готовы выпустить новую версию! И ваши тестеры могут протестировать полный пакет релизов, поэтому у вас есть уверенность в том, что каждая часть вашего процесса выпуска и установки работает, поскольку он ежедневно проводит тренировки.
CI: Это просто быстрые сборки, который работает каждый раз, когда кто-то проверяет в это говорит вам, если вы проверяете в не компиляциях коды, так что автор может сразу решить проблему и свести к минимуму нарушения в другие член команды. , Вы можете тратить много времени, когда 4 или 5 программистов получают последний код, а затем обнаруживают, что они не могут выполнять какую-либо работу в течение 2 часов, пока Фред не установит свою плохую проверку. Знание об сломанной сети позволяет вашим программистам избегать выполнения Get, если код не был проверен как работающий.
Для реализации NB и CI вам сначала нужно создать сборку, которая будет запущена на вашем сервере.
Если у вас есть работающий TFS, а затем создать сервер сборки вам просто нужно установить ваши средства разработки (VS2008 и все остальное, необходимый для сборки кода, таких как библиотеки 3 участника/инструментов для сборки и т.д.), как будто это ПК разработчика, и он готов к использованию в качестве сервера сборки.Просто щелкните правой кнопкой мыши по папке «Builds» и «Create new build», и вы сможете учесть большую часть ее, когда идете. Вы должны дать ему имя, настроить сопоставления рабочего пространства, чтобы сообщить ему, где построить код, и настроить папку вывода для «отбрасывания» результатов, и вам будет хорошо идти.
Возможно, вам потребуется настроить настройки ваших проектов, чтобы сделать эту работу хорошо, например. разработчики страшны при размещении ссылок на «C: \ Projects ...» в своих решениях, которые часто ломаются, когда проект перемещается на диск D: сервер buid и т. д. Кроме того, довольно раздражающе, сервер сборки будет создавать код в в разных местах, чем у ваших компьютеров-разработчиков, поэтому вы можете обнаружить, что части процесса сборки сломаются, и вам придется перенастроить такие вещи, как фиксированные местоположения ссылок и т. д., чтобы они работали как на машинах Build, так и на Dev.
Добавить как можно больше процесса (очистить, получить код, построить его, запустить модульные тесты, обфускать двоичные файлы, выставить двоичные файлы, установить инсталляторы, установить значки, скопировать в папку развертывания), автоматизировать, чтобы NB постройте все, и вы получите полностью освобождаемый продукт при нажатии одной кнопки. Компьютеры хорошо разбираются в этом, поэтому не оставляйте склонным к ошибкам и дорогим, чтобы запустить человеческое рабство весь день, чтобы сделать установщика!
Установите NB, чтобы выполнить полную перестройку (это должно быть по умолчанию) и используйте настройки триггеров, чтобы они запускались каждую неделю (например, 1 час). NB должен строить все (хорошая, тщательная сборка).
Скопируйте настройки сборки NB, чтобы создать сборку CI. В файле проекта MSBuild задайте следующие свойства: IncrementalGet = true, IncrementalBuild = true, ForceGet = false. Это преобразует его в быструю инкрементную сборку. В Картинке рабочего пространства, Плащайте или удалите как можно больше папок, чтобы свести к минимуму количество кода, которое он получает от источника, чтобы помочь сохранить его быстро. Установите сборку только для сборки одного варианта (например, Release), чтобы она была быстрой сборкой. В триггерах (щелкните правой кнопкой мыши по сборке и отредактируйте его), установите его для сборки всякий раз, когда есть чек.
Запустите монитор сборки на всех машинах-разработчиках. Это помещает значок в лоток значка и дает вам дополнительные уведомления при каждом запуске, завершении и сбое сборки. Если ваша сборка CI не удалась, вы сразу же узнаете об этом.
Теперь вы должны иметь ночные сборки готовы для тестирования каждого утра, и каждый раз, когда кто-то проверяет в каких-либо изменениях, новая инкрементальная сборка начнется, и вы будете знать, в течение нескольких минут, если вы нарушили кодовая база в управлении источником.
(У нас есть третья сборка, которая является инкрементной тестовой сборкой. Это то же самое, что и сборка CI, но она также выполняет все наши модульные тесты. Это выполняется каждую ночь, и разработчики могут запускать ее, когда захотят для проверки базы кода на сервере (мы используем это как механизм стробирования, прежде чем продвигаться к тестовой ветке). Это намного медленнее, чем тест CI, поэтому он не используется для сборки CI - вы хотите, чтобы сборка CI как можно быстрее)
Примечание: Чтобы сделать работу CI, вам иногда потребуется выполнить полную перестройку. В диалоговом окне «Очередь сборки», введите эти параметры командной строки, чтобы заставить это:
/p:IncrementalGet=false;ForceGet=true;IncrementalBuild=false
Там нет никаких технических приемов, которые «лучше», чем CI. Вы можете (и должны) использовать CI в дополнение ко всем другим процессам, которые вы реализуете.
Спасибо за очень подробный ответ.Мне было интересно узнать, могу ли я получить некоторые подробности по автоматизации следующих функций: *** «Очистите, получите код, выполните его, запустите модульные тесты, запутайте двоичные файлы, подпишите двоичные файлы, установщики сборки, установщики значков, скопируйте в папку развертывания» * ** Как я могу автоматизировать его? Просьба немного рассказать об этом. Очень признателен. Спасибо –
Задачи по умолчанию MSBuild, созданные «create new build», сделают чистый сбор и сборку кода. Добавление пользовательских шагов сборки: щелкните правой кнопкой мыши сборку и «Просмотреть папку конфигурации» и найдите файл TFSBuild.proj. Это файл MSBuild на основе XML. Существуют разделы для настройки свойств для управления битами сборки, выбора конфигураций для сборки и тестирования модулей. Другие задачи требуют добавления команд MSBuild, таких как, для их выполнения - вам нужно будет провести некоторое исследование MSBuild, чтобы узнать об этом, поскольку это полностью зависит от того, что вам нужно делать в своей сборке. –
Спасибо Джейсону. :-) –