В чем смысл «сервера сборки»? [закрыто]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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