Какой смысл “Сервера Сборки”? [закрытый]

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

Сервер сборки дает вам своего рода второе мнение о вашем коде. При регистрации проверяется код. Если работает, значит качество кода минимальное.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я согласен с ответами на данный момент в отношении стабильности, отслеживаемости и воспроизводимости. (Много чего, правда?). Работая ТОЛЬКО для крупных компаний (здравоохранение, финансы) с МНОГИМИ серверами сборки, я бы добавил, что это также касается безопасности. Вы когда-нибудь видели фильм «Офисное пространство»? Если недовольный разработчик создает банковское приложение на своей локальной машине, и никто больше не смотрит на него и не тестирует его ... БУМ. Супермен III.

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

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

• Они изолируют среду Локальный Code Monkey разработчик говорит: «Он компилируется на моей машине», когда не компилируется на вашей. Это может означать несинхронизированные проверки или отсутствие зависимой библиотеки. Jar hell не так плох, как ад .dll; в любом случае использование сервера сборки - это дешевая гарантия того, что ваши сборки не выйдут из строя или не упакуют по ошибке неправильные библиотеки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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