2009-07-08 2 views
92

Я не работал в очень крупных организациях, и я никогда не работал в компании, которая имела «Build Server».Что такое «Build Server»?

Какова их цель? Почему разработчики не строят проект на своих локальных машинах, или они? Являются ли некоторые проекты настолько большими, что для его создания требуются более мощные машины за разумное время?

Единственное место, где я вижу, что сервер сборки полезен, - это непрерывная интеграция с сервером сборки, постоянно создающим то, что привязано к репозиторию. Я просто не работал над проектами, достаточно большими?

Кто-нибудь, пожалуйста, просветите меня: Какова цель сервера сборки?

ответ

85

В качестве причины на самом деле является огромным преимуществом. Сборы, которые идут на QA, должны появляться только из системы, которая строится только из репозитория. Таким образом, сборка пакетов воспроизводима и отслеживается. Разработчики вручную создают код для чего-либо, кроме собственного тестирования, опасны. Слишком много риски вещи не получает зарегистрировалась, устаревание с изменениями других людей и т.д. и т.п.

Joel Spolsky on this matter.

+7

Вещи становятся особенно волосатыми, когда разработчики строят против библиотек с кровотечением, не понимая этого, а затем получая ошибки «NoClassDefFound» повсюду во время тестирования, и все остальные задаются вопросом, что, черт возьми, пошло не так. (Это было проблематично в моей работе на Java, пока я не настроил Hudson, и мы переместили сборки QA на это). – MattC

+1

На самом деле это всего лишь причина для создания из чистой проверки, а не для создания из выделенного сборщика агентов по выделенной сборке -server. Выполнение автоматизированного сценария сборки в чистой проверке репозитория на локальной машине разработчиков уже дает большую часть преимуществ выделенного сервера сборки. – Kaiserludi

+0

Одним из основных преимуществ IMHO является то, что он заставляет вас использовать встроенную систему, которая будет работать на 100% автоматически и настоятельно рекомендует вам иметь кнопки с нулевым нажатием, чтобы начать работу. Дело не только в том, что у вас есть единственный источник для релизов и тестовых сборок, но также и о том, чтобы люди не запирали вашу систему сборки. – Clearer

1

Мы используем один, чтобы мы знали, что в коробках для производства/тестирования есть те же библиотеки и версии этих библиотек, которые установлены на сервере сборки.

4

Сервер сборки используется для сборки кода каждого пользователя, когда он установлен. Ваш код может компилироваться локально, но вы, скорее всего, не будете иметь все изменения, сделанные всеми остальными все время.

2

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

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

1

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

0

Сервер сборки дает вам второе мнение о вашем коде. Когда вы его проверите, код будет проверен. Если это работает, код имеет минимальное качество.

3

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

5

Сервер сборки является отличной концепцией для сервера непрерывной интеграции. Сервер CI существует для создания ваших проектов при внесении изменений. В отличие от этого сервер сборки существует для создания проекта (как правило, выпуска, против помеченной ревизии) в чистой среде. Это гарантирует, что никакие взломы разработчиков, настройки, несанкционированные версии config/artifact или незафиксированный код не попадают в выпущенный код.

3

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

Один из вариантов заключается в моделировании типичной конфигурации конечного пользователя.Продукт может работать на вашем компьютере, все ваши инструменты разработки и библиотеки настроены, но конечный пользователь, скорее всего, не будет иметь такую ​​же конфигурацию, как вы. В этом отношении у других разработчиков не будет такой же настройки, как и вы. Если у вас есть жесткий код где-то в вашем коде, он, вероятно, будет работать на вашем компьютере, но когда Dev El O'per попытается создать тот же код, это не сработает.

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

4

Я до сих пор согласен с ответами относительно стабильности, прослеживаемости и воспроизводимости. (Многие, правда?). ТОЛЬКО когда-либо работал в крупных компаниях (Health Care, Finance) с серверами MANY build, я бы добавил, что это также касается безопасности. Когда-либо видели фильм «Офисное пространство»? Если недовольный разработчик строит банковское приложение на своей локальной машине, и никто больше не смотрит на него или не проверяет его ... BOOM. Супермен III.

+0

абсолютно @Greg! Кажется, что все здесь пропустили эту часть. Я сейчас работаю над процессом контроля изменений для соответствия, который требует развертывания вторичного отдела для производства. Ну, если вы не хотите преподавать IT, как использовать Visual Studio и развертывать yada yada yada ... это дает вам способ сделать это быстрыми щелчками. Не уверен, как это считается «бесполезным», как говорили некоторые. – gcoleman0828

0

Кроме того, помните, что языки низкого уровня занимают гораздо больше времени, чем компилируются языки высокого уровня. Легко думать: «Хорошо, мой проект .Net составляет пару секунд! В чем дело?» В то же время мне пришлось возиться с некоторыми C-кодами, и я забыл, сколько времени требуется для компиляции.

+0

IMHO, это не столько о низкоуровневых, либо высокоуровневых языках, а скорее о сломанной/несуществующей модульной системе C (т. Е. Включать файлы) в сравнении с языками с функционирующей системой модулей. –

1

Вы правы, что разработчики могли создавать собственные машины.

Но это лишь некоторые из вещей, наш билд сервер покупает нас, и мы вряд ли изощренные производители сборки:

  • вопросы контроля версий (некоторые из них были упомянуты в предыдущих ответах)
  • эффективность. Devs не нужно останавливаться, чтобы делать сборки локально. Они могут запустить его на сервере и перейти к следующей задаче. Если сборки большие, то это еще больше времени, когда машина Dev не занята. Для тех, кто делает непрерывную интеграцию и автоматическое тестирование, еще лучше.
  • Централизация. У нашей сборки есть сценарии, которые создают сборку, распространяют ее в средах UAT и даже на стадию производства. Хранение их в одном месте уменьшает сложность их синхронизации.
  • Безопасность. Мы здесь не особо выделяемся, но я уверен, что системный администратор может сделать так, чтобы средства производственной миграции могли быть доступны только на сервере сборки определенными уполномоченными сущностями.
1

Может быть, я только один ...

Я думаю, все согласны с тем, что один должен

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

Но никто не заботится о автоматически построенных версиях. Когда что-то было сломано в автоматической сборке, но это уже не так - кого это волнует? Это незавершенное производство. Кто-то его исправил.

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

Итак, возможно, «сервер сборки» - это просто неправильное название, и на самом деле это «непрерывный тестовый сервер». В противном случае это звучит почти бесполезно.

26

Какова их цель?
Загрузите машины-разработчики, обеспечивающие стабильную, воспроизводимую среду для сборки.

Почему разработчики не строят проект на своих локальных машинах, или они?
Потому что со сложным программным обеспечением удивительно много вещей может пойти не так, если просто «скомпилировать». проблемы, с которыми я столкнулся:

  • неполные проверки зависимостей разных типов, в результате чего не обновляются двоичные файлы.
  • Публикация команд, не выполняющих молчание, сообщение об ошибке в журнале игнорируется.
  • Сборка, включающая местные источники, еще не внесенные в исходный код (к счастью, никаких сообщений о «чертовых клиентах» пока нет.).
  • При попытке избежать вышеупомянутой проблемы путем создания из другой папки некоторых файлов, выбранных из неправильной папки.
  • Целевая папка, в которой объединяются двоичные файлы содержат дополнительные ненужные файлы для разработчиков, которые shoulkd не будут включены в выпуске

Мы получили удивительное увеличение стабильности, поскольку все государственные выпуски начинаются с Достаньте из управления версиями на пустую папку , Раньше было много «смешных проблем», которые «ушли, когда Джо дал мне новую DLL».

Есть ли такие проекты, которые настолько велики, что необходимы более мощные машины для его создания в разумные сроки?

Что такое «разумный»? Если я запускаю пакетную сборку на своей локальной машине, есть много вещей, которые я не могу сделать. Вместо того, чтобы платить разработчикам за сборку, заплатите IT, чтобы купить реальную машину для сборки уже.

Это я просто не работал над проектами, достаточно большими?

Размер, безусловно, один фактор, но не единственный.

42

Серверы сборки важны по нескольким причинам.

  • Они изолируют окружающую среду Местного Code Monkey developer говорит: «Он собирает на моей машины», когда он не будет собираться на вашем. Это может означать несинхронизирующие проверки, или это может означать отсутствие зависимой библиотеки. Джар ад не так плох, как ад. в любом случае, используя сервер сборки, это дешевая страховка, что ваши сборки не будут таинственно терпеть неудачу или ошибочно упаковать неправильные библиотеки.

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

  • Они координируют (распределяют) разработку. Стандартный случай заключается в том, что несколько разработчиков работают на одной и той же базе кода. Система управления версиями является сердцем такого рода распределенной разработки, но в зависимости от инструмента разработчики не могут много взаимодействовать с кодом друг друга. Вместо того, чтобы заставлять разработчиков рисковать плохими сборками или беспокоиться о смене кода чрезмерно агрессивно, спроектируйте процесс сборки, когда автоматическая сборка может увидеть соответствующий код и обработать артефакты сборки предсказуемым образом. Таким образом, когда разработчик совершает что-то с проблемой, например, не проверяя зависимость нового файла, он может быть быстро уведомлен. Сделав это в поэтапной области, давайте укажем код, который был построен, чтобы разработчики не вытаскивали код, который нарушил бы локальную сборку. PVCS сделали это довольно хорошо, используя идею групп по продвижению. Clearcase может сделать это тоже с помощью меток, но для этого потребуется больше администрирования процессов, чем множество магазинов.

+12

+1 Получение программистов для документирования изменений в их среде сборки подобно скотоводству кошек. Они просто не могут вспомнить, на каком этапе они обновили свою .Net или Boost lib, если они понимают, что сделали это вообще. Наличие центрального сервера, делающего ежедневную сборку, улавливает их в действии вечером после того, как они проверяют код, и нет ничего такого, что мотивировало бы, как сказано: «Вы сломали сборку команды, что вы забыли?» – kmarsh

0

Сервер сборки используется для планирования задач компиляции (например, ночные сборки) обычно от крупных проектов, расположенных в хранилище, которое может иногда принимать более чем на пару часов.

0

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

3

Чтобы добавить то, что уже было сказано:

Бывший коллега работал в команде Microsoft Office и сказал мне полный сборки иногда потребовалось 9 часов. Это сосать, чтобы сделать это на машине ВАШ, не так ли?

 Смежные вопросы

  • Нет связанных вопросов^_^