Как вы производите сборку на сервере интеграции? - PullRequest
Новая
       16

Как вы производите сборку на сервере интеграции?

2 голосов
/ 03 мая 2009

Предполагая, что у вас есть два разработчика, работающие над проектом на своих ноутбуках (A и B). У каждого из них есть рабочие копии репозитория SVN, и они кодируют в VS. У каждого есть полнофункциональная копия приложения. Они возвращаются в SVN на каждом остановочном пункте.

У вас есть сервер интеграции / тестирования (C), у которого есть другая рабочая копия, которая обновляется всякий раз, когда вы хотите выполнить тестирование.

У вас также есть рабочий сервер (D), который имеет x-копию после сборки из C.

Скажем, код является проектом веб-приложения, поэтому требует явной сборки (в отличие от проекта веб-сайта, который просто берет исходный код и собирает на лету).

Как вы управляете этим на сервере интеграции (C)?

Если разработчики строят на своих машинах (A и B), затем отправляют библиотеки DLL на сервер интеграции (C) ... это не будет работать, потому что сервер интеграции должен взять код с обеих сторон и разработать общая DLL. Таким образом, весь исходный код должен попасть на сервер интеграции (C), быть там встроенным , и только необходимые файлы и DLL переданы в производство (D).

Как вы управляете сборкой на сервере интеграции (C)? У вас есть временная сборка из командной строки? Вы устанавливаете VS на сервер интеграции (C) и строите таким образом? Если вы делаете это из командной строки, как управлять необходимыми ссылками и другими настройками, которыми VS обычно управляет в файле CSPRJ или SLN?

Ответы [ 3 ]

2 голосов
/ 03 мая 2009

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

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

0 голосов
/ 03 мая 2009

Мы используем Cruise Control для постоянной интеграции на сервере интеграции. Наш скрипт круиз-контроля выполняет следующие шаги:

  • Загружает последний код из SVN на сервер cc.net
  • Выполняет файл MSBUILD для компиляции последнего загруженного кода
  • скопировать сборку релиза в отдельную папку
  • Мы поддерживаем отдельную папку для сборок "Release", поэтому этот же скрипт также фиксирует последнюю сборку в ветке SVN "Release"
  • Выполнить тестовые случаи [построено с использованием nUnit]
  • Отправка электронного письма, содержащего статус сборки и результаты выполнения теста

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

Когда на сервере интеграции все в порядке, мы просто «обновляем» ветку «release» на производственном сервере.

вы можете найти больше информации о cc.net здесь

если вам нужна помощь со скриптами, я, безусловно, могу вам помочь.

0 голосов
/ 03 мая 2009

Мы также используем хук subversion commit из нашего svn repo, который активирует сборку модульных тестов при каждом коммите. Мы объединяем различные сборки, поэтому интеграционные и веб-тесты запускаются, когда модульные тесты становятся зелеными. Кроме того, мы бы очень хотели объединить релизную версию в конце всего этого, но наши интеграционные тесты недостаточно стабильны для этого (нестабильные серверные среды с плохими соглашениями об уровне обслуживания - я ненавижу это!). На данный момент мы вручную запускаем сборку релиза. С точки зрения качества мы могли бы перейти от всех зеленых индикаторов к серверам приемочных испытаний, но это означает, что вы, вероятно, захотите, чтобы чередующиеся образы работали в приемочных испытаниях, поскольку система сборки может создавать довольно много простоев, если она каждый раз перераспределяется успешный коммит прошел весь путь. (В нашем проекте мы были бы недоступны большую часть времени с 10 до 14 часов, поскольку в это время непрерывный поток коммитов;)

...