Как правильно вести разразработку в PhpStorm?

Question

[hrvasiliy]

Копия проекта хранится локально, изменения выгружаются на сервер по нажатию ctrl+s. Часто необходимо выполнять различные команды используя artisan. Если команды выполняются на сервере, то необходимо вручную скачивать новые файлы в PhpStorm, если локально, то опять же приходится в ручном режиме заливать новые файлы на сервер.

Интересует, как правильно, в данном случае, вести разрабтку проекта на Laravel, используя PhpStorm?

Comments

[Станислав Почепко]

Очень странно написан вопрос. Можете префразировать? Особенно про момент с загрузкой и выгрузкой файлов.

[hrvasiliy]

Станислав Почепко: разработка ведется на сервере, копия проекта локальная. При каких либо изменениях, после сохранения файла, он загружается на сервер.

[Станислав Почепко]

hrvasiliy: А локально нет сервера? Это же не удобно. Помнится, в FTP синхронизации много настроек, но не скажу точно, может ли он загружать сразу на сервер всё.

[hrvasiliy]

Станислав Почепко: Ужа явно понял плюсы локальной разработки исходя из моей проблемы :)

[Станислав Почепко]

hrvasiliy: Попробуйте поискать, как работают люди с vagrant (homestead). Это тоже получается как удалённый сервер.

Answer 1

[Максим]

Tools->Deployment->Options
Выставляете галочку на Prompt when overr.....
Выставляете Automatic Upload в Tools->Deployment
В итоге после смены ветки/генерации кода/тдтп - изменения отправляются на сервер.

Но:
Разработка на удаленном сервере нужна только если Ваш проект сложный и развернуть полноценную рабочую версию тяжело. Например микросервисы. Когда их 20+ поднять полноценное приложение на локальной тачке тяжело, да и порой невозможно, ресурсов не хватит.

В остальных случаях:
Никогда не загрязняйте свою хост машину. Используйте vagrant + любой devops софт. Самое простое использовать puphpet. Используйте vcs(git/svn/mercurial), для контроля версий приложения.
Деплоить можно по разному, тут кто на что горазд, от сборки на локальной тачке и заливке через scp до CI(gitlab, capistrano, jenkins), это тема другого вопроса.

PS: также, если вы разрабатываете не на винде(лучше сразу отвыкайте), то можно смонтировать nfs директорию, которая будет автоматом подгружать ваши изменения, но уже на уровне операционной системы, а не IDE.

UPD:

UPD2: Под разработкой на сервере я подразумевал девелоперский сервер\контейнер.
UPD3: Upload External Changes должен выгружать изменения с сервера, но помоему он у меня не заработал по ssh, точно не помню, можете попробовать =)

Comments

[hrvasiliy]

Максим Пробовал, все что вы описали. Все же решил перейти на локальную разработку. Настроил, возник вопрос: Как работать с БД? То есть локальная + та, что на сервере.Дампы? Миграции?

[hrvasiliy]

Максим И еще хотел узнать, вы упомянули CI (gitlab). Хотелось бы узнать как-то подробнее, может быть вы объясните, может ссылку дадите, чтобы понять что это и с чем его едят..

[Максим]

hrvasiliy: По поводу БД, конечно используйте миграции, старайтесь максимально приблизить локальное окружение к продакшену (именно поэтому лучше использовать виртуалку. Когда проектов становится много, сложно поддерживать кашу из энвайроментов на одной физической тачке). Также для разработческого и тест окружения используйте фикстуры, чтобы наполнять базу стартовыми данными.
Насчет CI, погуглите continuous integration, это отдельная и достаточно большая тема. Решений очень много и кастомизируемость их высокая. По сути это система(простым языком), которая подготавливает ваш код к отправке на prod сервера (на самом деле куда угодно, intergration, test...). То есть она может с нуля собрать ваш проект, вылить на тестовый сервер, применить миграции и фикстуры, запустить там тесты и если все ок, то вылить это все на продакшен сервер, при этом она может делать это автоматически, например по хуку из github. Я не DevOps инженер, поэтому рассказать все тонкости я не смогу =)

[hrvasiliy]

Максим: Спасибо

[hrvasiliy]

Максим: Не подскажите, если при инициализации репозитория, в файле .gitignore записаны папки типа vendor, public/storage и т.д. Они же должны быть на сервере, почему ларавел предлагает их не коммитить? Или как быть в этом случае? При любом раскладе эти папки должны появиться на сервере...

[Максим]

hrvasiliy: vendor установит composer install, остальные походу тоже сам Laravel создает, не писал на нем, точно не знаю. Если они по дефолту в гит игнор, значит эти файлы\директории создаются при деплое\запуске каких то утилит в Laravel

[hrvasiliy]

Максим: Я понял вас, спасибо!

Answer 2

[Роман Сохарев]

Правильно - использовать систему контроля версий. Например git.
Если совсем правильно, то для деплоя нужно использовать, соответствующий инструмент (например Capistrano или любой другой аналог)
Для бедных, можно настроить банальный хук.
При пуше (или мерже) допустим в мастер, на рабочий сервер улетает хук. Обработчик хука в свою очередь стянет все изменения из репозитория системы контроля версий, и запустит все необходимые команды (миграции, прогрев кеша, и вообще всё, что душе угодно).

Answer 3

[Виктор]

Правильно вести разработку локально