Как у вас устроена работа с базами?
У нас сейчас Dev -> QA -> Prod
Dev — разработчики локально работают с этой базой
QA — тестовый стенд для заказчиков
но в этой схеме есть одна проблема, когда разработчик меняют в своем бранче базу, то ломается у других система, т.к. сущности в базе есть, а в коде других еще нет.
поэтому решили добавить еще один стенд Debug куда дженкинс будет собирать версии автоматом и накатывая миграции.
А Dev будет чисто базой разработчика, но тут возникает обратная проблема накат миграций от других разработчиков и где хранить эту базу "локально на компе разработчика или на сервере где лежит тестовая база"
надеюсь понятно. Жирным проблему основную выделил.
Ваши мысли привествую
По моему опыту, вот эта схема вполне рабочая:
> Dev будет чисто базой разработчика
То есть, каждый разработчик имеет свою собственную базу. Базу разработчика хранить на компе разработчика.
Накатывание миграций никаких трудностей не представляло на моей памяти, не сложнее чем mege в git.
Возможность такой организации зависит от размера базы понятно, и от того, можно ли допускать разработчиков к содержимому базы на продакшене.
Как вариант можно в базе которая у разработчика иметь усеченный (в каком-то виде) вариант данных из продакшена.
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, merge, Вы писали:
bnk>По моему опыту, вот эта схема вполне рабочая:
>> Dev будет чисто базой разработчика
bnk>То есть, каждый разработчик имеет свою собственную базу. Базу разработчика хранить на компе разработчика. bnk>Накатывание миграций никаких трудностей не представляло на моей памяти, не сложнее чем mege в git.
bnk>Возможность такой организации зависит от размера базы понятно, и от того, можно ли допускать разработчиков к содержимому базы на продакшене. bnk>Как вариант можно в базе которая у разработчика иметь усеченный (в каком-то виде) вариант данных из продакшена.
да, с данными тоже момент учитывая что у нас данные джобы накатывают с прода на тест.
а тут получается джобы не знают точное время когда запуститься и надо доступ на локальный комп с тестового или наоборот каждому разработчику поставить скл сервер локально и чтобы каждый имел свои джобы
а миграции от других как накатываются? Вася говорит\пм или автомиграции в конфигурации Dev?
Здравствуйте, merge, Вы писали:
M>Ваши мысли привествую
Версионирование базы + миграции. Обновил разработчик базу, написал миграции, выкатил. Другой разработчик обновился, при старте приложение обнаружило что база старая, накатило миграции до актуальной версии. Собрали версию для выкладки на QA, развернули, накатили миграции. И т.д.
Ключевой фактор это самодостаточность миграций. Никто не накатывает никакие изменения руками. Если для новой фичи требуются какие-то данные в базе, эти данные тоже накатываются миграцией. Аналогично, всегда есть возможность поднять базу с нуля из схемы и в ней уже будет необходимый набор данных.
Здравствуйте, merge, Вы писали:
M>да, с данными тоже момент учитывая что у нас данные джобы накатывают с прода на тест. M>а тут получается джобы не знают точное время когда запуститься и надо доступ на локальный комп с тестового или наоборот каждому разработчику поставить скл сервер локально и чтобы каждый имел свои джобы
Ну где я последний раз работал в конторе было все локально.
Бэкап базы из продакшена выкладывался на шару, с вырезанными или закодированным секретными данными, к которым у разработчиков доступа быть не должно (запускался специальный скрипт перед бэкапом).
Все остальное разработчики делали сами по инструкции (которую надо написать).
Необходимость такой секретности понятно зависит от организации.
Если у вас сейчас разработчики видят данные в базе в продашене, можно просто бэкапить базу из продакшена да и все.
Вообще сейчас с облаком весь этот процесс можно автоматизировать,
просто предоставляя готовую машину для разработки уже со всем установленным, типа Azure DevTest Labs.
Ну или dockerfile например, чтобы у разработчика все что надо установилось и ему не пришлось вручную это делать.
Наверное зависит от того, как у вас принято, какое окружение.
M>а миграции от других как накатываются? Вася говорит\пм или автомиграции в конфигурации Dev?
Я думаю это зависит от того, как именно у вас устроены миграции.
В проекте, про который я говорю, всё делалось командой, миграции это просто файлы исходников по сути.
Здравствуйте, merge, Вы писали:
M>Привет
M>Как у вас устроена работа с базами? M>У нас сейчас Dev -> QA -> Prod M>Dev — разработчики локально работают с этой базой M>QA — тестовый стенд для заказчиков
M>но в этой схеме есть одна проблема, когда разработчик меняют в своем бранче базу, то ломается у других система, т.к. сущности в базе есть, а в коде других еще нет. M>поэтому решили добавить еще один стенд Debug куда дженкинс будет собирать версии автоматом и накатывая миграции. M>А Dev будет чисто базой разработчика, но тут возникает обратная проблема накат миграций от других разработчиков и где хранить эту базу "локально на компе разработчика или на сервере где лежит тестовая база"
M>надеюсь понятно. Жирным проблему основную выделил. M>Ваши мысли привествую
Щас полно средств для версионного контроля бд, загрузил разработчик репозиторий к себе — автоматом встала нужная версия бд с которой он потом работает. От разных мастер-бд лучше избавляется в особенности если используется одна общая.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, merge, Вы писали:
M>>Ваши мысли привествую
M>Версионирование базы + миграции. Обновил разработчик базу, написал миграции, выкатил. Другой разработчик обновился, при старте приложение обнаружило что база старая, накатило миграции до актуальной версии. Собрали версию для выкладки на QA, развернули, накатили миграции. И т.д.
вы говорите что у разработчика на компе своя база?
просто если на всех разработчиков одна база то вот простой кейс с проблемой.
Вася изменил структуру таблицы в своей фиче которую закончит к концу недели и только потом смерджит. и в базе уже измененная таблица.
А из-за изменения структуру падает запуск у Пети.
M>Ключевой фактор это самодостаточность миграций. Никто не накатывает никакие изменения руками. Если для новой фичи требуются какие-то данные в базе, эти данные тоже накатываются миграцией. Аналогично, всегда есть возможность поднять базу с нуля из схемы и в ней уже будет необходимый набор данных.
на проде из-за многих нод миграции руками накатываются.
Вы версии баз как ведете? Привязываете к версии системы?
Здравствуйте, merge, Вы писали:
M>вы говорите что у разработчика на компе своя база?
Да, нет смысла на этом экономить. Если по какой-то причине не хочется держать базы на машине разработчиков, можно завести для каждого разработчика базу на общем сервере.
M>на проде из-за многих нод миграции руками накатываются.
В данном случае не принципиально, админ раскатывает миграции руками по чеклисту или какой-нибудь Chef/Puppet/Ansible делает то же самое автоматически
M>Вы версии баз как ведете? Привязываете к версии системы?
В базе табличка с номером актуальной версии, в приложении код, проверяющий что версия базы не меньше нужной. В зависимости от флага, приложение либо раскатывает миграции на базу, либо вообще не стартует и зовет админа. Когда хочешь поменять базу, пишешь миграцию и инкрементируешь номер версии. Многие системы версионирования БД устроены сходным образом, посмотрите на Liqubase или Flyway.
Здравствуйте, Miroff, Вы писали:
M>>вы говорите что у разработчика на компе своя база?
M>Да, нет смысла на этом экономить. Если по какой-то причине не хочется держать базы на машине разработчиков, можно завести для каждого разработчика базу на общем сервере.
+1, у каждого разработчика на компе своя база.
M>>Вы версии баз как ведете? Привязываете к версии системы?
M>В базе табличка с номером актуальной версии, в приложении код, проверяющий что версия базы не меньше нужной. В зависимости от флага, приложение либо раскатывает миграции на базу, либо вообще не стартует и зовет админа. Когда хочешь поменять базу, пишешь миграцию и инкрементируешь номер версии. Многие системы версионирования БД устроены сходным образом, посмотрите на Liqubase или Flyway.
Привязывать ни в коем случае не к версии системы, у базы должна быть свои "версия".
И лучше делать именно таблицу (а не просто цифру), в которой регистрировать все примененные миграции.
Таблицу, а не цифру, чтобы миграции можно было применять не строго в определенном порядке (при совместной работе может понадобиться).
То есть, таблица содержит записи всех миграций, которые применены к базе. При накатывании миграций проверяем, что соответствующая еще не была применена.
По такой схеме работает большинство инструментов которыми я пользовался по крайней мере.
Здравствуйте, merge, Вы писали:
M>Ваши мысли привествую
В одной из круных компаний, с которой довелось работать, все изменения баз проходили через отдельную команду, ответственную за внесение изменений в структуры баз данных.
Разработчики делали реквест на изменения, команда рассматривала реквест на целесообразность и соответствие внутренним стандартам, изменения вносились в репозитарий моделей данных и затем генерились скрипты, которые администраторы баз данных накатывали на DEV и QA, затем по результатам тестирования либо изменерия накатывались на PROD или откат бызы QA на предыдущие версии.
Немного скучнее, чем когда разработчики сами изменяют базы, но вполне работало.
