Как наилучшим образом организовать разработку и обновление сайта на laravel?

Question

[Yuri Kalnin]

При разработке приложения, я использовал сиды и каждый раз перезагружал миграции, вынес это в свою команду и юзал ее:

public function handle()
    {
        $this->call('optimize:clear');
        $this->call('migrate:refresh', ['--seed' => true]);
        $this->call('dusk');
    }

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

Хотелось бы отказаться от сидов, и работать с актуальными данными сайта, только у себя на локальном сервере.

Установил пакет spatie/laravel-backup который делает бекапы на продакшин сервере каждый день, сейчас собираюсь написать скрипт который будет выкачивать последний бекап бд и разворачивать в мою локальную среду разработки.

Еще есть папка upload (с загруженными пользователями данными) ее хочу тоже автоматизировать примерно таким же образом.

Только очень сомневаюсь в правильности такого подхода, наверняка есть настроенные схемы работы, подскажите как все организовать.

Comments

[Артём]

Гуглите в сторону CI/CD

Answer 1

[Ernest Faizullin]

на счет тестового сервера, мы делаем так, клонируем проект на новый сервер и в системе контроля версий создаем отдельную ветку для него (dev). Все доработки делаем в ветках которые ответвляются от production ветки и сливаются в dev ветку. При одобрении ветвление сливается обратно в production ветку

на локалке enviroment "local" на dev сервере "development", на продакшне "production" (учитывать env в коде при разработке) . Если база данных большая, то можно с локалки подключаться к БД на dev, но это не приветствуется, если разработчиков больше чем 1, лучше для своей локалки создать какой-нибудь свой бесплатный storage в 1TB типа https://stackstorage.com или что-то подобное

по крону делаются снимки с БД на всех environments каждый день ночью, в файловой системе хранятся только последние 5 дампов. Для дампов отдельный Storage, для картинок отдельный Storage, короче все Storage созданы по смыслу хранимых данных

PS: я думаю нет общего шаблона на все случаи жизни, но есть good practice

Comments

[Yuri Kalnin]

Есть несколько вопросов:

"Все доработки делаем в ветках которые ответвляются от production"

Ветка production - это по сути master?

" по крону делаются снимки с БД на всех environments каждый день ночью,"

а каким образом актуализируете БД на development и local? вручную или есть какое решение которое автоматизирует это?

[Ernest Faizullin]

да, продакшн это мастер
сиды и миграции делаем вручную, раньше пробовали автоматически это делать, но в некоторых случаях приводило к проблеме, когда несколько разработчиков проталкивают миграции одновременно

Answer 2

[Роман Франк]

На большом проекте, мы делаем бекап за последние сутки, дамп получается 200-300 мб. Его накатывает на тестовый или локалку.
Если нужно для тестирования период пару месяцев, тогда делаем бекап за пару месяцев.

Как отписали выше, и правда нет смысла бекапить всю базу

Comments

[Yuri Kalnin]

а каким образом актуализируете БД на local? вручную или есть какое решение которое автоматизирует это?

[jazzus]

Yuri Kalnin, зачем вам актуализировать бд на локал?

[Роман Франк]

Yuri Kalnin, вручную.

Но например можно делать в связке
1. Бекап на сервере по крону
2. Забор бекапа через rsync на машине где нужен дамп
3. Заливка бекапа

Все по крону можно сделать)

ps. такое же советует Дмитрий Казармин :)

Answer 3

[jazzus]

Я использую Git BitBucket + Laravel Forge с VPS

Последние изменения + миграции для бд закачиваются в Битбакет, который синхронизируется с Форге автоматом. Нажатием 1 кнопки все изменения выгружаются на сервер и создаются таблицы. Скрипт деплоя, env можно редактировать в сервисе. Также в форге есть крон и простой запуск бэкапа и др. команд через него. Проблем ни разу не было.

Comments

[Ernest Faizullin]

автоматические миграции при деплое это круто, но в некоторых случаях может привести к проблеме. Например, когда несколько разработчиков проталкивают разные изменения в миграциях. Случай редкий, но если такое произойдет, то будет много геморроя потом и может на полдня а то и более выключить процесс разработки)

[jazzus]

Ernest Faizullin, тонкости деплоя командой не знаю т.к. в команде не работал. Теоретически можно договориться с командой, чтобы делали выгрузку в гит сразу после создания миграций. И согласованный деплой. И снэпшот сервера перед деплоем. Но это теоретически) У Laravel есть еще один инструмент Envoyer. Он расширяет/дополняет Forge. Возможно там есть какие-то инструменты.

[Ernest Faizullin]

jazzus, согласен. очень важно соблюдать договоренности, тогда проблемы сведутся к минимуму

Answer 4

[Дмитрий Казармин]

На бою по крону делать бэкап. Бэкапы рсинком тянуть на локалку. На локалке либо по крону перед рабочим днем или просто при ручном запуске скрипта поднимать последний бэкап. Папку upload тоже тянуть рсинком