Зачем собирать проект на сервере?

Question

[WebDev]

Все современные приложения, которые собираются сборщиком, из коробки включают в .gitignore директории со сгенерированным приложением. То есть предполагается, что я залью сырые файлы на сервер, а там запущу команду сборки, например npm run build.
Мне лично удобнее (и кажется что правильнее) запускать npm run build на локальном компьютере и коммитить уже собранное приложение, поэтому я всегда убираю эти директории из .gitignore.
А что если во время сборки на сервере что-нибудь пойдет не так и приложение не соберется, а это все в продакшене? Зачем такой подход? Как поступаете вы?

Comments

[Сергей delphinpro]

На продакшн сервере ничего не собирается!
Сборкой занимается CI-сервер, он же деплоит собранное приложение на боевой сервер.

[Толстый Лорри]

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

[crdrads]

Сергей delphinpro, чушь. Свой говнолендос тоже обвешал CI-серверами?))

[Сергей delphinpro]

crdrads, подростковая болезнь — всё возводить в абсолют.
Нет конечно, сайт сайту — рознь. Если на сайте одна страница, его проще по ftp залить.

Answer 1

[Stalker_RED]

У софта, библиотек, и прочих зависимостей бывают версии. Еще и у железа отличия бывают.

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

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

Comments

[ТыжСисАдмин]

А ещё есть такая штука как "регистр" букв.
Особенно часто встречается бага у разрабов сидящих под виндой - путь к либе какойнить указан в нижнем регистре а физически либа лежит по пути с верхним регистром в названиях.

Винда такое прощает конечно, но в проде нафиг пошлёт и это при том что "кросс" сборка прошла без ошибок.

[crdrads]

Собираются СТАТИЧЕСКИЕ файлы, о какиъ глюках может идти речь?)) Они одинаковые вне зависимости от того как и где собраны, т.к. именно они отсылаются на миллион клиентов.

[stratosmi]

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

[Сергей delphinpro]

crdrads,
1. собирается не только статика
2. сборка проекта, это не только сборка, но установка зависимостей.

Банальный SPA с SSR - приложение собирается полностью и фронт и сервер.

Вспомним про существование composer в мире php - установка зависимостей.

Так что глюки вполне могут быть (и были в моей практике).

[Stalker_RED]

crdrads, а еще у него внезапно SSR, но вы продолжайте, очень увлекательно получается.

[Сергей delphinpro]

crdrads, я прошу прощения за предыдущий комментарий в резком стиле. Я думал вы просто "тупите", а на самом деле у вас банально не хватает знаний для ведения данной дискуссии. За сим откланиваюсь.

[Stalker_RED]

crdrads, это не я придумал.
Зачем собирать проект на сервере?

Некоторые вопросы авторы задают в довольно абстрактном виде, и получают абстрактные ответы.
А термин "сборка" вообще довольно размытая штука.

Answer 2

[Saboteur]

Предполагается, что "сервер" это не боевой сервер, где крутится приложение, а сервер сборки, например агент teamcity/jenkins/hudson.

Если же у вас на "боевом" сервере что-то пойдет не так, то это что? интернет пропадет, чтобы подкачать зависимости? Так а как юзеры будут тогда на нем работать?

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

Предполагается наличие pull request-ов, которые требуют успешного билда для merge

Если ты работаешь сам, то делай как тебе удобно. Если работаешь не сам - есть best practice

Answer 3

[Евгений]

Помимо уже перечисленного другими комментаторами.

Как только вы начнете работать не один, и с несколькими ветками, то все эти зависимости в Git дадут вам огромную головную боль при переключении и слиянии веток. Я работал с репозиторием, в котором было включено все. Даже скомпилированные .mo файлы gettext.

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

Comments

[WebDev]

Вы имеете ввиду, что у каждого разработчика генерируются разные файлы и проблемы при merge?

[hOtRush]

Особенно если работает больше одного человека.

[Евгений]

WebDev, и это, и при обновлении зависимости в одной из веток, получается конфликт при слиянии.

Answer 4

[abbaboka]

Да, конечно - вполне можно вполне собирать на месте, а потом заливать готовое.

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

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

Первопричина - в уникальности среды конкретного разработчика. У другого разработчика или на боевом сервере - могут быть другие наборы установленного ПО, другие версии, по-другому сконфигурировано. И даже уже подготовленный и собранный вами готовый "артефакт" может попросту не запуститься.

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

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

Да, да.
Метода с выделением процесса сборки более громоздка (в частности, нужно обеспечить уведомления при сбое сборки/чтение логов сборщика). И далеко не всегда целесообразна. Но более удобна для бОльших проектов. Где разработчик может не быть в состоянии отслеживать каждую сборку индивидуально.

Хорошо настроенная система просто не выкатит код в production, если "пошло что то не так на сервере". Но ее еще нужно настроить.

Answer 5

[Юрий Юрин-Комаров]

Ну, во-первых, нужно понимать - мы говорим о статических артифактах или динамических? Если статических, то все равно как и где собрать.
Если о динамических, то советую посмотреть в сторону волшебного слова "контейнеризация" и проблема разницы исполняемой среды уйдет в небытие.
Автор, дай больше конкретики, какой use case тебя тревожит

Comments

[WebDev]

У меня SPA приложение на VueJS, которое я сейчас перевожу на nuxt (SSR). На VueJS приложение я собираю на локальном компьютере уже больше года и ни разу никаких проблем не было. Не знаю как будет с nuxt (там nodejs).

[abbaboka]

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

А вот для бэкендов - можно и рассмотреть сборку на сервере (если разработчик не один; если не хотите отслеживать развертывание в production каждой версии лично).

Answer 6

[АртемЪ]

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

А нафига пихать в продакшен сырой продукт?
Пока не отладите полностью и не будете уверены в релизе никакого продакшена.

Answer 7

[Boris Köln]

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

В нормальных проектах сборка делается на специальном Continuous Integration сервере.

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