Всем привет. как правильно сделать поддомен на Ларавел.?

Он делается на уровне dns-зон, и веб сервера, а не на уровне лары

мне нужно в ларе использовать subdomains

используй

вот же описано

Всем привет. Сейчас разрабатываю вебсайт (не работал никогда в фирме, а команды, ситуативно: front-end + seo'шники + дизайнеры - то-есть back-end всегда писал в одиночку) и у меня появился вопрос - как организовать доступ к базе данных для других разработчиков back-end разрабов? Должен ли я как главный разработчик предоставлять доступ другим к production базе (через параметры для .env.example из slack'а, где я храню все логи, пароли и токены) или нужно организовать некое тестовое окружение (как-то сомнительно ведь кажется что новые разработчики должные проверять функционал на реальных данных)? Просто совсем не хочеться что бы произошло что-то вроде [Junior, который в первый день работы удалил базу данных с production](https://habr.com/ru/company/flant/blog/330750/)

Разработчикам по хорошему не нужен доступ к продовой бд

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

наймите девопса чтоб все настроить заодно и там все вопросы спросишь

он же поможет настроить деплой пайплайны и все такое

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

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

Можешь людям дамп базы давать с текстовыми данными)

Первая часть смешная, а вот про спид не зашло)

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

Есть еще faker, с помощью которого ты можешь наполнить таблицу, кароч инструменты есть, верное направление тебе дали, дерзай

Спасибо, в общем как я себе это вижу:

- Создаем .env.example с переменными которые используются на prod;
- Далее каждый разработчик запускает миграции (структура тестово-локальной БД = prod);
- После генерит seeders (на faker данных), и наполняет локальную БД;
- Пишет код, unit-тесты, потом migrations + seeder'ы под новые колонки/таблицы в БД (если нужно) и делает integration-тесты, а после уже отправляет все на Github* (+ ci/cd пайплайны);
- В результате я лишь получаю код bussiness-логики в репозитории и ставлю approve на pull-request'ах новых фич в master (либо staging, а после если все ОК - из staging в master);

Бейте по рукам если что-то не учел или неправильно понял. Очень буду благодарен за любые разумные дополнения/изменения предыдущего сообщения!

И у меня все равно остаеться вопрос как потом локальные миграции перенести/развернуть на сервер, если разработчики не имеют/не должны иметь доступ на production БД?