Комментарии 31
Статья вызывает смешанные чувства. С одной стороны, написана довольно добротно. Но с другой - затянута она просто чудовищно. Я листал, листал, листал, листал, листал, листал, листал и всё ждал - а где же будет про деплой-то? И долистал:ssh prod, git pull.
ОК, я понимаю - про ansible, docker или Github Actions будет написано в других частях, наверное. Но увидеть вместо этого букварь по работе с гитом я как-то совсем уж не ожидал. При том что представить себе юзкейс для такой последовательности действий я не могу. Если человек не использовал гит при разработке, для которой он, вообще-то, и нужен, то тащить его для деплоя как-то странно. Залить зип архив через ту же файлзиллу ему будет и проще, и привычнее. Ну то есть либо у него уже есть гит - и тогда половину статьи можно выкинуть, или гита нет - и тогда ту же половину можно выкинуть тоже (и написать гайд по файлзилле).
Причем и в самом этом букваре снова хромает логика. git push с локали без ключа, разумеется, не сработает. А этот кусок не разжёван. То есть либо текст всё-таки пишется в расчете на человека, который уже пользуется гитом - и тогда половину статьи можно выкинуть, либо всё это разжёвывание в мелкую кашицу всё равно не сработает, поскольку процесс сломается уже в самом начале.
То же самое касается композера. Ну если человек пишет под Ларавал, то представление о пакетном менеджере он же уже должен иметь. Зачем перегружать статью?
Или ликбез по символическим ссылкам. Ну ОК, я понимаю, что подводный камень, который стоило обозначить. Но свою целевую аудиторию, для которой делается это разжевывание, вы к этому моменту уже потеряли. Объем новой информации, которую может усвоить человек, довольно ограничен. И примерно к середине статьи он уже перестанет что-либо воспринимать.
Из плюсов - в статье, за исключением мелких деталей, написано всё по делу, без косяков. Что для нынешнего Хабра уже большое дело.
В целом у меня претензия, пожалуй, только к несоответствию между названием и содержанием. Это точно не гайд по деплою. Я бы предложил либо выкинуть раздел про гит (и таким образом избавиться от шизофренического "вам понадобится знание основ git, но мы их вам все равно расскажем"), либо переназвать эту часть как "Гайд по деплою web-приложений на Laravel для новичков. Часть 1, подготовка проекта на своем компьютере", добавить в нее руководство по созданию ssh ключей под венду, перелить в неё всю воду про композер и на этом завершить. С тем, чтобы люди, интересующиеся именно деплоем, могли с чистой совестью её пропустить.
А следующую часть назвать "Гайд по деплою web-приложений на Laravel для новичков. Часть 2, выкатываем на shared hosting" и там уже расписывать костыли для копеечного хостинга, с символическими ссылками и композером в репе. Оставив в ней только генерацию ключей, а за картинками заливки на гитхаб отсылать к предыдущей части.
Из замеченных косяков
Команду cat ~/home/"имя_пользователя"/.ssh/"имя_файла".pub надо конечно заменить на
cat ~/.ssh/имя_файла.pub.Устанавливать upstream для клонированного репозитория не нужно, он ставится автоматом. То есть пассаж про программистов, любящих эффективность можно выкинуть.
В разделе про символические ссылки не объяснена причина, по которой мы их используем: что название готовой корневой папки веб-сервера на хостинге тупо не совпадает дефолтным названием публичного фолдера в ларавле, и самый простой способ их помирить - это как раз символическая ссылка.
Ну и в целом рекомендую проверить весь описанный воркфлоу на чистой системе, причём как удаленной, так и локальной.
Комментарий вызывает смешанные чувства. С одной стороны написан добротно, но затянут чудовищно. У людей посты меньшего объема, чем ваш комментарий.
Норм коммент) Наименование не соответствует. Статья в целом не про деплой, а про гит, composer, laravel, переменные окружения и пр. Web-приложенния это не только php и laravel. Есть java spring, flask, django, rails, go, js и др. Деплой это не только копирование по ftp, git push и pull и выполнение команд. Есть специальные библиотеки, docker, docker-compose, kubernetes, ci/cd разные.
Спасибо за уделённое время на изучение моей статьи и подробный комментарий. Всегда есть к чему стремиться, со всеми замечаниями согласен.
Уже давно занимаюсь созданием обучающих материалов и уделяю внимание "разжёвыванию", так как считаю, что хуже умолчать про какую-то деталь, чем лишний раз её проговорить. Статья рассчитана на новичков, которые смогут выполнить всё пошагово с простым объяснением основ.
Правки учту! 🤝
P.S. Скриншоты для статьи сделаны при полной проверке её содержания на shared-хостинге.
Что на хостинге все выверено - это видно. Локальную-то систему надо тоже на чистой проверять :) Понятно что ключи были добавлены в незапамятные времена и про них, естественно забываешь. Но без ключей эта "пошаговая инструкция" ломается на первых же шагах.
Ну и всё-таки я не уверен, что в статье про деплой надо рассказывать про гит. Я этак могу ещё десяток тем накатать, которые тоже надо обязательно осветить. Например основы Ларавля. Ведь статья про деплой приложения на этом фреймворке? Ну так надо привить человеку базовые навыки работы с ним. И про MVC заодно рассказать.
Ну и всё-таки я не уверен, что в статье про деплой надо рассказывать про гит.
Всё правильно автор сделал. Это действительно надо рассказывать, потому что очень многим это непонятно. Начиная от всяких фрилансеров, которые до сих пор всё через файлзиллу таскают, заканчивая многими мидлами и даже сеньорами с галер, у которых в конторе всё деплоит специально выделенный человек. Мы однажды отдали на аутсорс фрилансеру вёрстку на реакте. Солидное портфолио, серьёзные проекты, вроде хороший специалист. Говорю ему: "давай ключ SSH, добавим тебя в репозиторий". А он такой "А чё, в смысле? Это же фронтенд, зачем там SSH?"
Например основы Ларавля. Ведь статья про деплой приложения на этом фреймворке?
Во-первых, заголовке нет ничего про Ларавель. Во-вторых, деплой на других фреймворках выглядит точно так же. К примеру, если деплоить Drupal, то единственное отличие в том, что вместо artisan нужно использовать drush. Аналогично в Symfony. В-третьих, на других языках приложения деплоятся абсолютно так же:
git pull
пакетный_менеджер install
консольная_тулза_фреймфорка накат_обновлений_БД (опционально)
рестарт прилаги (для асинхронных приложений типа next, nuxt, ruby И т.д.)npm run prodНа многих ли шаред хостингах есть npm? Мне ещё ни разу не встречалось. Приходится скомпилированные стили держать в репозитории.
Спасибо за подробнейшую статью. Мне как раз привлекателен Laravel тем, что его удаётся запустить на обычном shared-хостинге рядом с привычными вордпресс-сайтами. Делал это дедовским способом заливки и распаковки архива через файл-менеджер хостинга (плюс импорт SQL-дампа БД).
Но вот с символической ссылкой возник вопрос. На сайте Таймвеба написано про неё:
"хотя данный способ является оптимальным для размещения на нашем хостинге сайтов на Laravel, при его использовании могут наблюдаться проблемы с записью логов сайта в log-файлы на аккаунте."
В связи с чем я заморочился и умудрился запустить laravel-проект не трогая симлинки, а отредактировав файл .htaccess, добавив в него такие строки:
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_HOST} ^laravel\.mysite\.ru$ [NC]
#RewriteRule ^((?!laravel/).*)$ /laravel/public/$1 [L,NC]
RewriteCond %{REQUEST_URI} !^/laravel/ [NC]
RewriteRule (.*) /laravel/public/$1 [L]Таким образом у меня получилось запустить Laravel-проект на поддомене laravel.<мойсайт>, поместив файлы проекта в папку "public_html/laravel".
Соответственно вопрос к знатокам - насколько этот способ приемлем? С точки зрения слабо подготовленных пользователей, пожелавших установить себе на хостинг мой опенсорсный проект, этот способ вроде бы как даже проще - можно прямо готовый такой файл .htaccess брать, заменять имя домена на своё и не морочить себе голову работой с незнакомой пугающе чёрной консолью.
Деплой это хорошо, но важная часть rollback на предыдущую версию опущена...
Деплой пуллом из гит-репозитория самый простой. Но вводить несколько команд для обновления - такое себе. Нужно упростить.
Добавляем в composer.json
"scripts": {
"down": [
"php artisan down --render=\"errors::503\" --retry=60 --status=503"
],
"up": [
"php artisan up"
],
"deploy": [
"composer down",
"php artisan optimize:clear",
"git reset HEAD --hard",
"git pull",
"composer install",
"php artisan migrate --force",
"npm ci",
"npm run build",
"php artisan optimize",
"composer up"
]
},и обновляемся одной командой composer deploy
Ну или то же самое пишем в какой-нибудь deploy.sh
Простите, но это прям следующее издание книги "Вредные советы".
Пообщайтесь с девопсами, они научат вас как нужно делать.
Может для собственного пет проекта на коленке такой подход и норм. Но для продакшен решений - нет.
Обратите внимания на заголовок, "для новичков" и "часть 1". Автор последовательно описывает разные способы деплоя от простого к сложному, и в следующей части обещает рассказать о более "продвинутых" способах с бо́льшей автоматизацией процесса.
Новичок, возможно, даже git не использует в своей работе и для него даже такой способ будет большим прогрессом в проф. развитии )
Заодно мотивирует наконец-то начать использовать git. Вы удивитесь возможно, но до сих пор есть люди, которые его не использует 🤷♂️
Так может имеет смысл сразу учиться делать правильно? Чтобы потом не перерабатывать весь флоу.
Чтобы научиться делать правильно, надо сначала понять, что именно, и для чего ты делаешь. Перед тем как применять автоматизацию, надо сначала научиться делать руками. Иначе вместо специалиста, который может разобраться в проблеме, мы получим попугая, который только и может, что повторять инструкцию, и встает в тупик, если что-то пойдет не так. И в этом смысле подход автора - от простого к сложному - совершенно оправдан.
Спасибо за комментарий. Буду рад, если расскажете какие советы тут вредные чтобы откорректировать. Много было дельных советов в комментариях, которые я учёл и добавил корректировки в статью
Ну скорректировали-то вы мелочи, а главные два косяка - стуктура статьи (при которой про собственно деплой от силы десятая часть этой стены текста) и ошибка при git push (которая полностью стопорит вест этот развесистый воркфлоу) - так и остались.
И, кстати. На Stack Overflow есть правило: никаких "update" в ответах. Хочешь исправить - испрвляй прямо в тексте. Что совершенно логично, если подумать: тот человек, который уже читал ответ, не будет читать его снова, и для него отличать добавления от исходного текста нет смысла. А тому, кто будет читать в будущем, тем более неинтересно спотыкаться о какие-то "update".
Статья просто огонь! Самое то для человека, который уже имеет опыт, но хочет систематизировать в голове всю последовательность действий и закрыть какие-то пробелы!
Сердечко от всех души ❤
Статья - супер! Большое спасибо от начинающих в Ларе
А сами исходники проекта можно получить? Спасибо!
https://github.com/moonshine-software/moonshine тут в readme.md все ссылки на демо-репозитории
Огромное спасибо! От Вашего почитателя и подписчика на ютуб
Публикации
Гайд по деплою web-приложений для новичков. Часть 1. Shared-хостинг