Какова цель выделенной сборки машины?

75

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

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

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

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

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

Zibbobz
источник
166
«необходимость покинуть мой офис со всей необходимой информацией, а затем спуститься по лестнице в другой офис, чтобы выполнить простую сборку [...]» Что именно вы имеете в виду? Вы физически получаете доступ к этой машине, чтобы создать сборку?
Винсент
13
Настоящий WTF - это Clearcase, который хуже всех современных альтернатив с открытым исходным кодом. На каком языке (ах) этот проект и насколько большой / сложный сборка?
pjc50
7
Вы используете инструменты? Git / SVN и Jenkins / Team City / Осьминог / TFS и т. Д.? Или вы просто заходите на другой компьютер, загружаете Visual Studio или что-то еще ... копируете проект, загружаете, компилируете ... Вы используете профессиональные инструменты или делаете это вручную?
WernerCD
84
Моя сборочная машина где-то в Южной Каролине, а я в Сиэтле. Уверяю вас, я не спускаюсь по ступенькам лестницы, чтобы использовать его. Я думаю, что в последний раз у меня был физический доступ к сборочной машине, когда я был стажером, отвечавшим за сборочные машины для компиляторов Microsoft в 1994 году, когда они помещались в небольшой шкаф; теперь они где-то целый центр обработки данных. Получить машину в вашей сети; еще лучше, возьмите это в облаке и заставьте кого-то еще позаботиться об этом.
Эрик Липперт

Ответы:

138

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

Сервер сборки предлагает гораздо больше. Сервер сборки допускает CI (непрерывную интеграцию), что означает, что он будет автоматически собираться при каждом нажатии вашей VCS (например, git), может даже выполнять модульные тесты, если они у вас есть, и допускает «развертывание одним щелчком». Серверы сборки могут уведомлять вас по почте в случае неудачной сборки или тестирования. Они предлагают исторические данные и тенденции о том, что произошло.

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

В мире Java одним из наиболее часто используемых серверов сборки является Jenkins. Jenkins прекрасно работает и со сборками C ++ (поскольку вы, похоже, используете эти два языка). Jenkins называет себя сервером автоматизации, поскольку он может выполнять все виды задач, которые не должны быть связаны с программированием и сборкой.

Traubenfuchs
источник
3
На самом деле я не касался c ++ с колледжа, но я могу понять его полезность. Хотя в этом случае я думаю, что то, что мы на самом деле делаем, может быть далеко от намеченной цели.
Зиббобз
21
Для некоторых языков (в частности, C ++) наличие выделенного блока с большей вычислительной мощностью также может быть полезным, поскольку компиляция выполняется относительно медленно.
enderland
31
Непрерывная интеграция означает больше, чем просто наличие сервера сборки, - это также означает, что каждый интегрирует изменения друг друга как можно чаще, чтобы избежать проблем слияния "большого взрыва". В противном случае на месте.
Роб Кроуфорд
Хотя мне нравится сила, которую пример дает тому моменту, который я здесь изложил, я все же считаю, что последний абзац совершенно не нужен в этом ответе.
Пьер Арло
3
«Выделенная сборочная машина просто предлагает преимущество, заключающееся в том, что она никогда не блокирует работу разработчика и не развертывает ее с централизованной машины». Это не совсем так. Аскер отметил, что очень легко иметь нечистую среду на компьютере разработчика. Включенные библиотеки и другие переменные среды могут изменить результат сборки. Выделенная машина должна иметь хорошо документированную среду, позволяющую легко строить отдых.
TafT
107

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

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

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

Саймон Б
источник
37
+1 Количество раз, когда что-то работает на компьютере разработчика, а не на остальной части его команды ...
user2259716
45
Этот. Основной целью строительства на другой машине, чтобы иметь воспроизводимые сборки ; в частности, за счет исключения несвязанных вещей, разнородных переменных среды и т. д. ... из уравнения.
Матье М.
9
Продолжим это: используйте новый, чистый образ контейнера, с которого вы начинаете каждую сборку. Затем загрузите сценарий начальной загрузки системы. Это действительно гарантирует воспроизводимые сборки.
Матиас Кун
9
@MatthiasKuhn: действительно (для байта за байтом) воспроизводимые сборки требуют гораздо большего, cf: reproducible-builds.org wiki.debian.org/ReproducibleBuilds
ninjalj
1
Кроме того, только то, что версия продукта для Linux собирает и проходит тестирование на рабочем столе Linux, не означает, что будет создана версия для Windows или Mac.
Соломон Слоу
53

Основной причиной наличия выделенной машины для сборки является получение согласованных сборок независимо от того, кто выполняет сборку. Рабочие станции разработчиков редко (читай: никогда) идентичны. Трудно понять, что в каждой сборке используются одни и те же точные версии зависимостей, компиляторов и т. Д. Одна из худших проблем сборок для рабочих станций разработчиков заключается в том, что разработчики могут собирать код, который не проверен в управлении версиями.

Не ясно, какую платформу / язык (ы) вы используете, но в идеале у вас должен быть сервер сборки, который извлекает данные непосредственно из системы контроля версий. То есть, когда требуется сборка, она извлечет исходный код из заданной версии репозитория и автоматически скомпилирует его. Это требует использования автоматизированных инструментов сборки для сценария сборки. Если у вас этого нет, это должен быть шаг № 1.

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

JimmyJames
источник
Кроме того, дополнительная устойчивость к вирусу.
Джошуа
@ Джошуа Что дает тебе эту идею?
jpmc26
14
@ jpmc26: на сборочном компьютере установлено гораздо меньше программного обеспечения, меньше удаленных точек доступа, и никто не открывает веб-браузеры для случайных интернет-сайтов на нем.
Джошуа
19

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

  • Во-первых, настройте удаленный доступ к серверу сборки! Если вы собираете вручную, набрав команду «make», это означает, что вам больше не нужно ходить в другой офис, чтобы набирать «make», вы можете просто подключиться по SSH к серверу сборки и ввести «make». Если вы еще не используете make или подобную систему сборки, используйте такую ​​систему сборки.
  • Во-вторых, установите среду непрерывной интеграции, которая автоматически извлекает последние изменения из системы управления версиями (у вас есть система управления версиями, верно? Если нет, это будет дополнительный шаг) и создает их. Я рекомендую Дженкинс. Настройте Jenkins для запуска модульных тестов и интеграционных тестов на уровне системы (у вас есть и то, и другое, верно, если нет, то создайте их, начиная с модульных тестов и заканчивая интеграционными тестами на уровне системы).
  • В-третьих, если вы обнаружите, что совместное использование одной и той же машины с другими группами проблематично (например, если у вас другое мнение о том, какую операционную систему и какую версию и битрейт следует использовать), рассмотрите возможность использования виртуализации. Хороший сервер сегодня может работать с огромным количеством виртуальных машин. Возможно, вы могли бы настроить себя на 32-битную и 64-битную машины, чтобы знать, что сборка работает на обеих архитектурах.
  • Наконец, в этом может не быть необходимости: если вам абсолютно необходимо иметь выделенный компьютер, например, если производительность вашего приложения очень важна, а другие одновременно выполняющиеся сборки / тесты слишком сильно влияют на ваши результаты, установите выделенный аппаратный сервер, чем только вы используете. Однако на последних серверах, которые могут иметь до 40 виртуальных ядер ЦП или даже больше, довольно просто создать несколько виртуальных машин, которые не имеют доступа к одним и тем же ядрам ЦП.

Я бы посчитал общую машину намного лучше, чем ручные сборки. В моем текущем проекте сейчас используется виртуальная машина, но из-за необходимости тестов производительности интеграции на системном уровне мы переходим на выделенный сервер с 40 виртуальными ядрами ЦП, из которых для тестов производительности требуется 17.

juhist
источник
16

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

Вы говорите так, как будто это плохо.

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

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

Вы все еще выполняете сборку вручную, и это не хорошо.

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

Фил В.
источник
5
«Ты говоришь так, как будто это плохо». Это может быть, если у них есть свободное правление, чтобы установить любой мусор, который они хотят. Если они удаленно или физически получают доступ к нему, я не вижу, как это можно предотвратить.
jpmc26
7
«Вы говорите так, как будто это плохо. Теперь у вас есть общий сервер сборки, через который собираются все ваши сборки - ваша и другие команды. Согласованность сборки? Проверка». Это полная противоположность последовательной сборки! Если какая-либо другая команда решит обновить свой компилятор или любой другой инструмент, вы вдруг столкнетесь с совершенно другой средой сборки. Это довольно худший сценарий (за исключением того, что у вас нет машины для сборки).
Во
1
Договорились о желании иметь автоматический процесс создания новых сборок, но в то же время вы также хотите виртуализировать агенты сборки, чтобы убедиться, что ваша среда сборки находится под вашим собственным контролем. Виртуальные машины - удивительный инструмент для разработчиков, и вы должны максимально использовать его.
Во
@ Voo Это вряд ли худший сценарий, это средний сценарий. То, что в настоящее время у спрашивающего, является худшим сценарием. (Также обратите внимание, что если вы никогда не воспроизводите сборки, случайные обновления компилятора не являются большой проблемой)
user253751
@immibis Вы читали эту часть в паранах сразу после цитируемой части? Это худший вариант, если задействован сервер сборки. Проблема с невоспроизводимыми ошибками заключается в том, что вы не можете делать исправления, если за это время вся ваша среда сборки изменилась. Это не составляет большой проблемы, если у вас есть только одна выпущенная версия, которая держится близко к транку, но во всех других случаях это довольно плохо.
Во
1

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

Для надежной системы сборки, особенно при совместном использовании машины сборки с другими пользователями, нормально запускать сборки в виртуальной машине. Это гарантирует, что другие пользователи не смогут изменить поведение ваших сборок, установив свои собственные версии приложений или библиотек, от которых зависит ваш код. Большим преимуществом этого является то, что виртуальная машина может быть легко скопирована, а также может быть легко клонирована на любой другой ПК (включая вашу собственную машину разработки).

Грэхем
источник
1

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

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

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

Джим У
источник
4
это , кажется, не предлагает ничего существенного над точкой сделана и объяснена в ранее 6 ответов
комар