Показываю на примере четвертого Галпа, как сделать автоматическую синхронизацию локального проекта с удаленным.
Деплоить в продакшн, особенно без контроля версий чревато последствиями и лучше никогда так не делать. Но у меня большинство проектов простые, я работаю в них без команды, без использования гита и могу идти на любой разврат не использовать девелоперские версии, синхронизируя изменения сразу с боевым сайтом. То есть деплоить на лету сразу на сервер. Такая синхронизация удобна и при работе с дев‑версиями: можно синхронизироваться с дев‑версией, а деплоить по запросу. Так тоже часто делаю.
Сборщики проектов (Grunt, Webpack, Gulp, etc) в свое время перевернули с ног на голову все мое представление о веб‑разработке. Точнее поставили с головы на ноги. А rsync раскрыл глаза на ущербность всех этих фтп. Я уже писал в своем фейсбуке, что в прошлом году перешел с третьего на четвертый Галп.
Поэтому, весь код в примерах будет для Gulp 4.
В Gulp 3 он работать не будет.
Дальнейший текст подразумевает, что у вас уже установлен Node.js, Gulp, создан локальный проект, настроена вся компиляция, конкатенация, минификация, браузерсинк и прочие радости жизни.
Мы начинаем непосредственно с подключения gulp-rsync к Gulp:
npm i gulp-rsync gulp --save-dev
Тут все просто, стандартно и легко гуглится в случае проблем. Важно только не перпутать gulp-rsync c rsync — это разное.
Мне не сразу удалось настроить полноценную синхронизацию.
То есть чтобы было так: я добавляю новый локальный файл — он появляется на сервере, удаляю файл локально — он удаляется на сервере.
Вроде простая задача, но с первого раза не завелась: файлы закачивались, но не удалялись.
Теперь открываем в проекте gulpfile.js
и подключаем gulp-rsync, определив его в константу rsync
const rsync = require('gulp-rsync');
Затем создаем новую функцию deploy()
для дальнейшего экспорта задачи.
function deploy() { return src('./') .pipe(rsync({ root: './', hostname: 'login@server', destination: '/path/', include: ['.htaccess'], exclude: ['node_modules', '/Thumbs.db', '/.DS_Store'], clean: true, compress: true, recursive: true, archive: true })) }
Gulpfile.js
у меня обычно лежит в корне проекта. Поэтому, пути относительно него. Чтобы работала синхронизация важно в return src()
задать './'
. Без этого файлы с сервера почему-то не удаляются.
Остальное все как обычно:
root
— локальный путьhostname
— логин, сервер, для авторизации предварительно нужно сгенерировать SSH-ключи и разрешить по ним доступ на сервереdestination
— путь на сервереinclude
,exclude
— что разрешаем и запрещаем синхронизироватьclean
— разрешить удаление файлов и директорий, которые отсутствуют локально (опасная штука, пользоваться осторожно)compress
— сжатие при передачеrecursive
— рекурсивная передачаarchive
— включение режима архивации
Полная документация на npmjs (англ.)
Дальше просто экспортируем таск и выполняем его при необходимости.
exports.deploy = deploy;
Но можно пойти дальше и добавить деплой в параллель дефолтного таска. Здесь есть еще один важный момент с которым мне пришлось столкнуться — мониторинг файлов. Так как Gulp у меня в корне проекта, нужно обязательно исключить из мониторинга директорию node_modules
.
watch(['.//', '!./node_modules//']).on('change', deploy);
То есть Gulp будет запускать таск при изменении всех файлов, кроме тех, что в директории node_modules
. Если этого не сделать, будет очень сильно нагружаться процессор компьютера. Что особенно критично для ноутбуков. Да, и необходимости гонять туда-сюда эти модули смысла нет.
В качестве заключения отмечу, что предложенный мной механизм довольно экстремальный, рассчитан больше на профессионалов, людей, которые понимают, что делают, зачем и чем это все может обернуться. Поэтому, будьте предельно внимательны, осторожны и перед запуском обязательно сделайте резервную копию.
Делаю сайты на Вордпресс с 2008 года, в том числе уникальные инструменты для решения сложных бизнес‑задач.
Подробнее