В чем смысл "Build Server"?

Ответ 1

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

Джоэл Спольский по этому вопросу.

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

Ответ 12

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

Ответ 13

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

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

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

Ответ 14

Может быть, я единственный...

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

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

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

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

Итак, возможно, "сервер сборки" является просто неправильным, и это фактически "непрерывный тестовый сервер". В противном случае это звучит почти бесполезно.

Ответ 15

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

Ответ 16

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

Ответ 17

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

Ответ 18

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