Я не работал в очень крупных организациях и никогда не работал в компании, у которой был «Сервер сборки».
Какова их цель? Почему разработчики не создают проект на своих локальных машинах? Неужели некоторые проекты настолько велики, что требуются более мощные машины, чтобы построить их в разумные сроки?
Единственное место, где я вижу, что сервер сборки полезен, - это непрерывная интеграция с сервером сборки, постоянно создающая то, что передано в репозиторий. Я просто не работал над достаточно большими проектами?
Кто-нибудь, просветите меня, пожалуйста: для чего нужен сервер сборки?
источник
Серверы сборки важны по нескольким причинам.
Они изолируют среду. Местный разработчик Code Monkey говорит: «Он компилируется на моей машине», когда не компилируется на вашей. Это может означать несинхронизированные проверки или отсутствие зависимой библиотеки. Jar hell не так плох, как ад .dll; в любом случае использование сервера сборки - это дешевая гарантия того, что ваши сборки не выйдут из строя или по ошибке не упакуют неправильные библиотеки.
Они сосредоточены на задачах, связанных со сборками. Это включает в себя обновление тега сборки, создание любого пакета распространения, запуск автоматических тестов, создание и распространение отчетов о сборке. Автоматизация - ключ к успеху.
Они координируют (распределенное) развитие. Стандартный случай, когда несколько разработчиков работают над одной и той же кодовой базой. Система контроля версий является сердцем такого рода распределенной разработки, но в зависимости от инструмента разработчики могут не сильно взаимодействовать с кодом друг друга. Вместо того, чтобы заставлять разработчиков рисковать плохими сборками или беспокоиться о чрезмерно агрессивном слиянии кода, спроектируйте процесс сборки, при котором автоматизированная сборка может видеть соответствующий код и обрабатывать артефакты сборки предсказуемым образом. Таким образом, когда разработчик совершает что-то с проблемой, например не проверяет новую файловую зависимость, он может быть быстро уведомлен. Выполнение этого в поэтапной области позволяет вам пометить построенный код, чтобы разработчики не извлекали код, который может нарушить их локальную сборку. PVCS неплохо справился с этим, используя идею рекламных групп. Clearcase тоже может сделать это с помощью этикеток, но для этого потребуется больше администрирования процесса, чем может предоставить большинство магазинов.
источник
Какова их цель?
Возьмите на себя нагрузку на машины разработчика, обеспечьте стабильную воспроизводимую среду для сборок.
Почему разработчики не создают проект на своих локальных машинах?
Потому что со сложным программным обеспечением удивительно много вещей может пойти не так, если просто "скомпилировать". проблемы, с которыми я столкнулся:
У нас потрясающий рост стабильности, поскольку все публичные выпуски начинаются с перехода из системы управления версиями в пустую папку. Раньше было много «забавных проблем», которые «исчезли, когда Джо дал мне новую DLL».
Неужели некоторые проекты настолько велики, что требуются более мощные машины, чтобы построить их в разумные сроки?
Что «разумно»? Если я запускаю пакетную сборку на своем локальном компьютере, я не могу многое сделать. Вместо того, чтобы платить разработчикам за завершение сборки, заплатите ИТ-специалистам, чтобы они уже купили настоящую машину для сборки.
Я просто не работал над достаточно большими проектами?
Размер, безусловно, является одним из факторов, но не единственным.
источник
Сервер сборки - это отдельная концепция для сервера непрерывной интеграции. Сервер CI существует для создания ваших проектов при внесении изменений. В отличие от этого существует сервер сборки для сборки проекта (обычно релиза с помеченной ревизией) в чистой среде. Это гарантирует, что никакие взломы, настройки, неутвержденные версии конфигурации / артефакта или незафиксированный код не попадут в выпущенный код.
источник
Сервер сборки используется для сборки каждого кода, когда он зарегистрирован. Ваш код может компилироваться локально, но вы, скорее всего, не будете получать все изменения, вносимые всеми остальными постоянно.
источник
Чтобы добавить к уже сказанному:
Бывший коллега работал в команде Microsoft Office и сказал мне, что полная сборка иногда занимает 9 часов. Было бы отстойно делать это на ВАШЕЙ машине, не так ли?
источник
Необходимо иметь «чистую» среду, свободную от артефактов предыдущих версий (и изменений конфигурации), чтобы гарантировать, что сборки и тесты работают и не зависят от артефактов. Эффективный способ изолировать - создать отдельный сервер сборки.
источник
Я согласен с ответами на данный момент в отношении стабильности, отслеживаемости и воспроизводимости. (Много чего, правда?). Работая ТОЛЬКО для крупных компаний (здравоохранение, финансы) с МНОГИМИ серверами сборки, я бы добавил, что это также касается безопасности. Вы когда-нибудь видели фильм «Офисное пространство»? Если недовольный разработчик создает банковское приложение на своей локальной машине, и никто другой не смотрит на него и не тестирует его ... БУМ. Супермен III.
источник
Эти машины используются по нескольким причинам, и все они пытаются помочь вам создать превосходный продукт.
Одно из применений - моделирование типичной конфигурации конечного пользователя. Продукт может работать на вашем компьютере со всеми настроенными инструментами разработки и библиотеками, но конечный пользователь, скорее всего, не будет иметь ту же конфигурацию, что и вы. В этом отношении и у других разработчиков не будет такой же настройки, как у вас. Если у вас есть жестко запрограммированный путь где-то в вашем коде, он, вероятно, будет работать на вашем компьютере, но когда Dev El O'per попытается построить тот же код, это не сработает.
Кроме того, их можно использовать для отслеживания того, кто последним сломал продукт, с каким обновлением и где произошел регресс продукта. Каждый раз, когда регистрируется новый код, сервер сборки строит его, и, если он терпит неудачу, ясно, что что-то не так и виноват пользователь, который совершил последний.
источник
Для стабильного качества и для получения сборки «с вашего компьютера», чтобы выявлять ошибки среды и чтобы любые файлы, которые вы забыли зарегистрировать в системе управления версиями, также отображались как ошибки сборки.
Я также использую его для создания установщиков, так как они занимают много времени на рабочем столе с подписью кода и т. Д.
источник
Мы используем один, чтобы знать, что в производственных / тестовых коробках установлены те же библиотеки и версии этих библиотек, что и на сервере сборки.
источник
Для нас это управление и тестирование. С сервером сборки мы всегда знаем, что можем построить нашу основную «магистральную» линию из системы контроля версий. Мы можем создать основную установку одним щелчком мыши и опубликовать ее в Интернете. Мы можем запускать все наши модульные тесты каждый раз, когда код проверяется, чтобы убедиться, что он работает. Собирая все эти задачи на одной машине, становится проще выполнять их многократно.
источник
Вы правы, что разработчики могли строить на своих машинах.
Но вот некоторые из вещей, которые нам покупает наш сервер сборки, а мы вряд ли являемся опытными производителями:
источник
Может, я единственный ...
Я думаю, что все согласны с тем, что нужно
Но никого не волнуют автоматически созданные версии. Когда что-то было сломано в автоматической сборке, но это уже не так - кого это волнует? Работа в стадии разработки. Кто-то починил.
Когда вы хотите создать релизную версию, вы запускаете сборку из репозитория. И я почти уверен, что вы хотите пометить версию в репозитории именно тогда , а не каждые шесть часов, когда сервер работает.
Так что, возможно, «сервер сборки» - неправильное название, и на самом деле это «сервер непрерывного тестирования». В противном случае это звучит бесполезно.
источник
Сервер сборки дает вам своеобразное второе мнение о вашем коде. При регистрации проверяется код. Если работает, значит качество кода минимальное.
источник
Кроме того, помните, что языки низкого уровня компилируются намного дольше, чем языки высокого уровня. Легко подумать: «Послушайте, мой проект .Net компилируется за пару секунд! Что в этом такого?» Некоторое время назад мне пришлось возиться с некоторым кодом C, и я забыл, сколько времени требуется для компиляции.
источник
Сервер сборки используется для планирования задач компиляции (например, ночных сборок) обычно больших проектов, расположенных в репозитории, что иногда может занять более пары часов.
источник
Сервер сборки также дает вам основу для условного депонирования, имея возможность захватывать все части, необходимые для воспроизведения сборки, в случае, если другие могут иметь права на владение.
источник