Comments 26
И самый главный вопрос — зачем? Gulp, Webpack, etc — это те штуки, которые нафиг не упали на проде висеть. Компиляция должна происходить локально и в прод деплоиться уже собранные сырцы.
А ли я не прав?
При работе с нескольких систем, проще на сервер повесить сборщики, нежели каждый раз настраивать и запускать. В продакшен сборщики отключаются
Мой пример подходит для совсем лайтовых систем, которые не висят на автоматизированных Build & Deploy системах и, скорее всего, поддерживаются одним человеком.
Вряд ли для личного мини сайта или блога вы будете писать проект с использованием CI, но мелкие правки вы предусматриваете в будущем.
А если привык к хорошему (Gulp), то частичку этого можно и оставить, пусть и таким образом)
Кстати, отмечу, что даже не все свои проекты я запускаю с выгрузкой собранных сырцов. Некоторые настолько специфичны, что содержат большое количество хотфиксов, которые просто не удобно все билдить заранее, поэтому на продакшете всё же остается возможность запустить билд, хоть это и делает система деплоя)
Не ожидал в 2016 году прочесть статью о новом остроумном способе редактирования файлов на боевом сервере
Конечно это не туториал для профессиональных разработчиков мощных систем, но вот помочь связке Программист + Верстальщик, работающим с одним сайтом (каким-нибудь там dev.mysite.ru) это несомненно может.
А с git состояние файлов вы потом как синхронизируете? Push прямо с удаленного сервера?
Прошу, не рассматривайте это как позыв к действию: «Как начать писать свой проект… с галпом через админку», это лишь попытка помочь тем, кто уже использует такой процесс разработки, либо просто не нуждается в чем либо более современном.
Тогда почему бы не запускать Gulp локально, а на сервер закидывать собранный результат?
Сразу отпадает куча проблем по установке ненужной Node.js на сервер и интеграции с php-кодом.
— верстальщик правит один файл, а ему нужно заливать другой.
— верстальщик забывает залить все SCSS файлы на сервер, от этого страдают потом все.
— верстальщик не в состоянии адекватно настроить генератор на разных машинах (плохой аргумент, но и такое было)
— программист не хочет настраивать генератор и вообще лезть во фронтенд, но необходимо сделать мелкую правку. Здесь и сейчас…
Я не считаю интеграцию с PHP или установку NodeJS на сервер проблемой. Это (как и все остальные проблемы) задача, которая требует решения, возникшая во время выполнения другой задачи)
Перечисленные вами проблемы — это признак уже не маленького проекта.
Для такого уже можно и заморочиться с процессом деплоя, хотя бы с локальной машины. Всяко получится лучше, чем изголяться прямо на продакшене, рискуя его уронить.
Серёжа знает CMSку и готов покодить немного, Юра может чото поверстать, но дико далёк от PHP и системы. Вместе они делают какой-то сайт для подруги жены Серёжы… Я бы не парился там с деплоем, но скрасить время вёрстки для Юры я не откажусь)
Можно и заморочиться, но я вижу больше плюсов в таком подходе (читать как «более простом»).
Процесс деплоя тянет за собой одеяло с целой кучей проблем, к которым система может быть не готова, всё зависит от изначально выбранного подхода.
— Нет деплоя, есть админка, работаешь прямо на сервере? Статья для тебя.
— Хочешь автоматизировать деплой и не ставить на сервер инструменты для билда? Ищи другой подход, статья не об этом.
Как-то так.
Не вижу смысла спорить, всё что вы говорите верно, и, конечно, на много удобнее на крупных проектах с командой, но повторюсь, это пример реализации для конкретного процесса разработки и поддержки сайта (не процесс разработки сайта то обсуждать нужно).
Зачем для сайта подруги жены нужен Gulp? Может проще обойтись без препроцессоров, транспиляторов и прочих штук?
Если уж заморочились с настройкой Gulp, то надо делать до конца. А то получается такое ни туда ни сюда решение, где сборка происходит серверной магией и непонятно куда копать и к кому идти, если что-то сломалось.
Пользователь там один, а правки могут делать как программист, так и верстальщик.
Может ещё можно придумать, но это действительно неудобно. В таком процессе работы может даже и не быть Git'а совсем…
В данном случае мы живём лишь в рамках IDE и админпанели, которая за нас частично автоматизирует процесс. Просто и удобно (основной акцент на «просто»).
— Можно ли этот процесс легко перенести на другую машину?
— А что если на самом сервере нужно сделать правки, не имея IDE под рукой?
— А заливается автоматически (ярый противник автоматического деплоя, особенно при работе с боевым сервером :D)?
Просто именно с такими трудностями столкнулись я и мои друзья при работе над сайтом при «заливке готовых ресурсов на боевой»…
— Если без IDE то не получится )
— Заливается автоматически при сохранении (пока с этим проблем не было)
Да и чес слово, ну проще же поставить один раз это всё на сервак, чем потом разбираться что на другой машине ещё и ноды нет, а последняя нода не билдит то что нужно и т.д.))
Жёстких требований к «отсутствию билда на сервере!» не было, поэтому почему бы не попробовать))
На другой машине ноды нет? Докер, Вагрант… Нет?
Говорю же, срочно что-то поправить в рабочем сайте.
При чём тут докер или вагрант?
Да, на ноутбуке жены в поездке стоит всё окружение и настроен деплой)))))
Я пропустил слово "срочно поправить" в треде, перечитал, всё равно не нашёл. Куда смотреть?
Даже выделил (см. пункт «Итог»).
Но даже не в «срочно» смысл, просто неохота поднимать окружение на всех машинах. Да, и такое бывает. Не переводите всё на промышленные масштабы)
Запускаем Gulp с вотчерами на обычном хостинге через админпанель