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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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