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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Хорошо настроенная система просто не выкатит код в production, если "пошло что то не так на сервере". Но ее еще нужно настроить.
Ответ написан
@BorisKorobkov
Web developer
А что если во время сборки на сервере что-нибудь пойдет не так и приложение не соберется, а это все в продакшене?


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

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

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

Войти через TM ID
Похожие вопросы
12 дек. 2018, в 05:58
1000 руб./за проект
11 дек. 2018, в 21:41
500 руб./за проект
11 дек. 2018, в 20:00
600 руб./в час