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