а команды, ситуативно: 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 БД?
почитай про гит флоу. вот ты тот чел который мержит в мастер и все там развернет
нет... ты сливаешь все в мастер. Заходишь по ssh на прод. Делаешь гит пул. Запускаешь сидеры миграции, переносишь инфу из example env в env
Ещё лучше
вполне рабочая схема если нет автодеплоя
да прошу прощение за «локаль»
спасибо)
Где лучше хранить пароли, логины и токены - на уровне linux или nginx?
Обсуждают сегодня