Правильная работа с фреймворком?

Question

[Оптимус Пьян]

1. На чём держите локальную копию проекта? OpenServer? Что делать при несовпадении версий PHP или БД на локальной версии и серверной?
2. Какой метод обновления самый правильный? Чё-то над FTP и SFTP пошла мода смеяться, а системы непрерывной интеграции типа Jenkins для меня пока сложноваты. Или я зря комплексую?

Answer 1

[Saboteur]

Над ftp надо смеяться, а SFTP может использоваться и внутри Jenkins, тем более что авторизация в sftp возможна по ключам, без необходимости вводить пароль.

Jenkins очень простой - тупо планировщик задач. Реально посидите один-два вечера - очень полезно.

Но никто не мешает вам обновляться так, Как вам удобнее. Только действительно FTP - несекьюрно.

P.S. В идеально продакшн и локальный енвайрнмент должны совпадать.

Comments

[Stanislav]

А почему над ftp смеются?)

[Оптимус Пьян]

Stasgar: могут перехватить ваш конфиг-файла а там пароли к базе, соль и т.д.

[Александр Новиков]

Stasgar: Совершенно неперсистентная работа с данными. Нельзя откатиться к какому-то состоянию, файлы меняются не одновременно, может произойти сбой в момент заливки и замены файлов (например место кончилось на сервере), и зальется не целиком проект, невозможность применять миграции. Да причин действительно слишком много. Как минимум после перехода на более совершенные способы деплоя ftp становится уже субъективно дико неудобным)

[Saboteur]

Любым способом, данные меняются не одновременно и место может закончиться. Сам по себе sftp это инструмент, который выполняет лишь часть деплоя.

Answer 2

[Евгений]

1) Docker
2) Docker-machine

Answer 3

[Александр Новиков]

1. Как уже ответили выше - Vagrant, либо Docker.
Первый попроще, можно конфиг например онлайн набить и попробовать сразу puphpet.com . По сути Вагрант - это просто отдельный сервер, к которому ты обращаешься (он крутится в виртуальной машине, т.е инкапсулирован). И прокинуты отдельные порты в хост систему + файлы проекта синхронизируются.
Докер более мейнстримный, более умно использует ресурсы, но порог входа повыше будет. Зато его можно использовать для деплоя.
В целом и то, и то позволяет делать конфиги и работать с ними в состоянии близком или идентичном тем, что на продакшене.
2. Если сейчас работаешь с FTP и SFTP - то переходи на связку ssh + git. Это как бы следующий шаг.
примерно как будет выглядеть разработка и деплой :
Работаешь с проектом под основной машине, в виртуалке (докер/вагрант) выполняешь код, добиваешься рабочей бизнес логики. Пишешь миграции для данных, если надо, и изменения в коде+миграции коммитишь в репозиторий. Потом по ssh подключаешься к продакшн серверу, где развернут проект, по git pull скачиваешь все изменения и применяешь их, и запускаешь миграции если надо.
если надо - можешь откатиться.

Comments

[Оптимус Пьян]

Тут подразумевается что на боевом сервере с проектом тоже git установлен так? Из всего написанного я только не очень понимаю слово "миграции"...

[Александр Новиков]

Оптимус Пьян: да, на боевом сервере тоже git. собственно даже на недорогих виртуалках с доступом по ssh гит есть почти всегда.
Миграции - это описание манипуляций с базой данных в php коде. Во всех популярных фреймворках они есть из коробки, если не повезло и проект legasy - то можно поставить например phinx через composer.
Как работают миграции: если надо добавить новую таблицу в базу / новую колонку - то ты не просто тупо заходишь в phpmyadmin и выполняешь там что хотел - если в команде больше одного разработчика и у каждого по локальной базе, + на девелопе/проде еще по одной - поди зайди в каждом и напрямую создай. У кого-то забудешь, опечатаешься - и сломается что-то, а что - придется вручную искать.
Обычно пишут миграции - классы, имеющие метод up и down , условно. Допустим up создает таблицу и новую колонку, down удаляет их, т.е откатывает базу к предыдущему состоянию. Т.е есть метод применения изменений, и их отката. Миграции выполняются последовательно, т.е можно их десяток написать при работе над задачей, не держа в голове, что ты там локально наменял, а потом разом применить на проде.
Прелесть этого подхода в том, что один раз описал - потом применяешь на любом количестве серверов одной простой командой с возможностью отката. Плюс изменения структуры базы логируются в коде, и всегда можно найти, что где сломалось и пошло не так

Answer 4

[Александр Беляков]

1) Open Server. Во избежание несоответствия версий PHP делаю настройку версий в Open Server.
2) Для обновления файлов использую WinSCP и протокол SCP.
P.S.: Для работы с БД использую HeidiSQL.

Comments

[Sergej]

WinSCP ?
Т.е. вы вручную переносите файлы и перезаписываете их на сервере?
Вы серьезно?
Не советуйте такого людям больше, пожалуйста.

[Оптимус Пьян]

Doc: Ну по существу это то же самое что SFTP...

[Sergej]

Оптимус Пьян: Именно. О чем и речь.

Answer 5

[Sergej]

1) sudo apt-get install nginx, php.... (в win10 можно включить для этого ubuntu bash)
2) Конечно же git или др. контроль версий.

Или как советовал Евгений

Answer 6

[Сергей delphinpro]

1) OpenServer с профилем под проект.
2) Над git pull тоже смеются, а мне пофиг, у меня работает и не жалуюсь.

Comments

[Сергей Семенко]

А почему над git смеются?

[Александр Новиков]

Сергей Семенко: ну при росте проекта становится недостаточным. А по сути если проект небольшой - маленькое веб-приложение или просто сайт - то такой смех это наверное просто снобизм, мол, реальные парни деплоят через docker, git прошлый век. А по факту git pull отлично выполняет свои задачи при проектах соответствующего размера и сложности. Как только деплой начинает заключаться не только в обновлении backend кода, а в применении кучи миграций, обновлении конфигов, прогреве кэша, и все это на нескольких серверах - разумеется гита уже не будет хватать. Но когда проект становится таким - вопрос уже звучит не как "ftp или git pull", и проблемы появляются другого уровня ;)

[Сергей Семенко]

Александр Новиков: спасибо за разъяснение

Answer 7

[Yustas Alexu]

FTP/SFTP заменяется гитом. Вместо open server лучше использовать виртуалку с линуксом на борту.