|
версионирование БД
|
|||
---|---|---|---|
#18+
Hett, Админы обычно малоинициативные. Работа такая. 24 на семь и... Работает, не трогай!)) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2019, 18:00 |
|
версионирование БД
|
|||
---|---|---|---|
#18+
llemingПросто время растет не линейно. Вроде месяц назад можно было скрипты накидать и за час полтора протестить. То теперь сильно сложнее. Продуктовый стенд уже так быстро не склонировать, ну и естественно количество ресурсов выделенных не растет. - хороший пример на тему того как "технический долг" начинает негативно влиять на проект. Можно продолжать и дальше "есть кактус" и начать огребать все более крупные проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2019, 18:04 |
|
версионирование БД
|
|||
---|---|---|---|
#18+
KachalovllemingГлавная проблема с обновлениями существующих клиентов. БД с данными и скрипты изменения схемы в БД могут выкидывать ошибки Приходится ручками релизы аккуратненько накатывать (авто деплой уже нетривиален). Кроме того это занимает теперь время. Кто как решает проблему? - странно, использовал Liquibase, там хранится вся история изменений, можно накатить с любого места, таких проблем не возникает Liquibase и Flyway требуют аккуратного кодинга в части DDL операций. Типичный сценарий. В один change-set положиле две (и более) DDL команды. Например на добавление индекса. И создание новой колонки. Добавление индекса прошло успешно. Добавление колонки упало с ошибкой не хватило места в табличном пространстве. Далее. С точки зрения Liq/Fly вы стоите на шпагате. С одной стороны индекс установлен. С другой стороны ченж сет не встал. Попытка выровнять ситуацию только интерфейсом Liq/Fly ни к чему не приводит. Далее сценарий уже падает на существующем индексе. Нужно ручное вмешательство. Да и вообще. Уйма чего. Тоесть заавтоматизировать на 100% процедуру передачи обновления у меня лично никогда не получалось. Слава богу что есть рукастые люди со стороны заказчика. А если их нет. И пятница вечера. То хрен вам а не релиз. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2019, 19:23 |
|
версионирование БД
|
|||
---|---|---|---|
#18+
maytonНапример на добавление индекса. И создание новой колонки. Добавление индекса прошло успешно. Добавление колонки упало с ошибкой не хватило места в табличном пространстве. Далее. С точки зрения Liq/Fly вы стоите на шпагате. С одной стороны индекс установлен. С другой стороны ченж сет не встал. Попытка выровнять ситуацию только интерфейсом Liq/Fly ни к чему не приводит. Далее сценарий уже падает на существующем индексе. Нужно ручное вмешательство. - стоит освоить preconditions (так это называется в терминологии Liquibase, к сожалению, с FlyWay не работал) и проблема решена. Любые операции необходимо делать с предварительной проверкой - это элементарная культура программирования. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2019, 19:41 |
|
версионирование БД
|
|||
---|---|---|---|
#18+
Вово. Но это тот еще гемор. Вообще мало разработчиков этим заморачиваются. Занимаются SQL/Java примерно в соотношении 1:10000 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2019, 20:02 |
|
версионирование БД
|
|||
---|---|---|---|
#18+
maytonНо это тот еще гемор. Вообще мало разработчиков этим заморачиваются. - это странно, так как без проверок тупо второй раз тест не прогонишь ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2019, 20:05 |
|
версионирование БД
|
|||
---|---|---|---|
#18+
Kachalov- стоит освоить preconditions (так это называется в терминологии Liquibase, к сожалению, с FlyWay не работал) и проблема решенаТам (в flyway) их просто нет, вся его концепция заключается в том, что вот есть папка со скриптами, он их упорядочивает по названию (не по чейнджлогу, т.е. еще и конвенция на имена существует) и запускает, если есть две "немного" отличающиеся базы, то нужно делать две папки, вот такой топорный инструмент: никакой разницы с тем, что скрипты запускает человек нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2019, 20:10 |
|
версионирование БД
|
|||
---|---|---|---|
#18+
llemingПродуктовый стенд уже так быстро не склонировать, ну и естественно количество ресурсов выделенных не растет.Мое мнение такое, что клонирование продуктовой базы - путь вникуда, оно полезно для Operations чтобы оценить сколько времени будет занимать обновление и сделать финальную проверку всего и вся (ну еще для нагрузочного тестирования крайне полезно), а вот для разработки (Transition) так делать неправильно, довод такой: рано или поздно подобные клонирования приводят к тому, что в багтрекинге баги начинают заводиться в виде "если Марья Ивановна тыкает туда-то, то ой", а не в виде "при выполнении вот таких условий происходит то и то", как итог происходит полнейшая деградация QA, что в принципе у вас уже и произошло: мы делаем в базе новые структуры, а потом ждем когда заказчик их заполнит вместо QA, чтобы потом поверх накатить другие структуры. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2019, 20:17 |
|
версионирование БД
|
|||
---|---|---|---|
#18+
Обычно продуктовая БД засекюрена. И имеет неподъёмный размер. И клонирование в общем понимании этого слова скорее всего не используется. Практически выглядит это как просьба к местным DBA создать урезанную копию. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2019, 20:24 |
|
|
start [/forum/topic.php?fid=59&startmsg=39789776&tid=2121414]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
others: | 334ms |
total: | 454ms |
0 / 0 |