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

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

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

Собрав у себя локально и перелив на сервер, у которого отличается окружение - рискуете получить кучу глюков, и чем больше оно отличается, тем сильнее рискуете.
Ответ написан
saboteur_kiev
@saboteur_kiev
build engineer
Предполагается, что "сервер" это не боевой сервер, где крутится приложение, а сервер сборки, например агент teamcity/jenkins/hudson.

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

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

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

Если ты работаешь сам, то делай как тебе удобно. Если работаешь не сам - есть best practice
Ответ написан
Пригласить эксперта
Ответы на вопрос 5
@immaculate
Программист-путешественник
Помимо уже перечисленного другими комментаторами.

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

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

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

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

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

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

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


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

Хорошо настроенная система просто не выкатит код в production, если "пошло что то не так на сервере". Но ее еще нужно настроить.
Ответ написан
yurymkomarov
@yurymkomarov
Творите о себе мифы. Боги начинали именно так.
Ну, во-первых, нужно понимать - мы говорим о статических артифактах или динамических? Если статических, то все равно как и где собрать.
Если о динамических, то советую посмотреть в сторону волшебного слова "контейнеризация" и проблема разницы исполняемой среды уйдет в небытие.
Автор, дай больше конкретики, какой use case тебя тревожит
Ответ написан
А что если во время сборки на сервере что-нибудь пойдет не так и приложение не соберется, а это все в продакшене?
А нафига пихать в продакшен сырой продукт?
Пока не отладите полностью и не будете уверены в релизе никакого продакшена.
Ответ написан
@BorisKorobkov
Web developer
А что если во время сборки на сервере что-нибудь пойдет не так и приложение не соберется, а это все в продакшене?


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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
RealtimeBoard Пермь
от 90 000 до 140 000 руб.
Smartbics Нижний Новгород
от 50 000 до 70 000 руб.
//stablecode Вена
от 110 000 до 140 000 руб.
21 февр. 2019, в 02:24
8 руб./в час
20 февр. 2019, в 23:54
1000 руб./за проект
20 февр. 2019, в 23:26
25000 руб./за проект