Расскажите, как осуществляется версионный контроль в СУБД?
Интересует тот же вопрос. и тоже для постгрес. Пока используем в основном вариант 1 и делаем бекапы на случай если кто-то косякнет. Но также задумывались про варианты 2 и 3 (ранее реализовывали их на MS SQL) но тоже хочется чего то более простого...
Дано: 5 разработчиков создают веб-приложение, использующее постгрес. Как им взаимодействовать друг с другом?1. Есть продакшн, есть дев-база.
2. За схему и преобразования от одной до следующей версии отвечает один человек. Все изменения схемы через него.
3. Все преобразования пишутся на sql и коммитятся.
4. На дев-базу делаются бекапы после каждого отведения, хранятся в теплом месте.
5. Все тестовые данные запиливаются через sql и коммитятся по ходу разработки.
ЗЫ
то есть критических конфликтов между разработчиками в области базы нет - их разруливает один человек в команде.
любой фейл решается в два клика:
накатить базу из бекапа и дифф sql-скриптов от отведения ветки, до текущего момента.
Мы пользуемся вариантом 2. Со следующими особенностями:
1. часть таблиц создаётся приложением из метаданных. Если таблица в БД есть, но структура не соответствует метаданным, то приложение просто не стартует.
2. когда заканчивается разработка релиза новые скрипты вместе с приложением ставятся на чистую базу и с помощью подручных средств результат сравнивается с "копией продакшн" (по структуре). После чего один разработчик готовит патч с необходимыми изменениями который и будет отправлен заказчику.
Метод хорошо работает при умеренных объёмах данных. Пробовали применять его при разработки DWH, но оказалось не подъёмным, т.к. держать копию для каждого разработчика/группы оказалось очень дорого.
1. часть таблиц создаётся приложением из метаданных. Если таблица в БД есть, но структура не соответствует метаданным, то приложение просто не стартует.
2. когда заканчивается разработка релиза новые скрипты вместе с приложением ставятся на чистую базу и с помощью подручных средств результат сравнивается с "копией продакшн" (по структуре). После чего один разработчик готовит патч с необходимыми изменениями который и будет отправлен заказчику.
Метод хорошо работает при умеренных объёмах данных. Пробовали применять его при разработки DWH, но оказалось не подъёмным, т.к. держать копию для каждого разработчика/группы оказалось очень дорого.
Вариант 2 можно сделать без "вручную", что я и использую в своих проектах.
Можно сделать в какой то момент дамп продакшен базы и перенести его на дев. Новые таблицы, вьюшки и т.д. и т.п. создаются и переносятся вручную на прод. Для разработки в бд у каждого разраба своя ветка, из которой он и запускает файлы кода в ide. Из ветки мержим в транк, и выкатываем в релиз. Для мавена, например, есть плагин, который коммитит функции, процедуры,пакеты в ору.
Единственный косяк - если разрабы в один момент работают над одним пакетом - в этом случае при каждой компиляции будут затирать друг друга.
Единственный косяк - если разрабы в один момент работают над одним пакетом - в этом случае при каждой компиляции будут затирать друг друга.
Основные моменты такие. База хранит номер своей версии. Программисты пишут дельта-скрипты.
1)Делайте скрипты деперсонализации, которые во взятой с продакшена базе заменяют например паспортные данные на мусор.
2)В постгресе хранимые процедуры можно создавать в любом порядке, зависимости для них отслеживаются во время выполнения.
3)Используйте схемы. Один из вариантов использования схем - таблицы создаются в отдельной схеме, например data. Вьюхи и ХП в другой. Деплой новой версии может выглядеть так: делаются alter table и create table. Затем создается новая схема version_XYZ, в этой новой схеме создаются все вьюхи и хранимые процедуры. Для выбора версии клиент после коннекта выполняет команду 'set search_path to version_XYZ,data';
2)В постгресе хранимые процедуры можно создавать в любом порядке, зависимости для них отслеживаются во время выполнения.
3)Используйте схемы. Один из вариантов использования схем - таблицы создаются в отдельной схеме, например data. Вьюхи и ХП в другой. Деплой новой версии может выглядеть так: делаются alter table и create table. Затем создается новая схема version_XYZ, в этой новой схеме создаются все вьюхи и хранимые процедуры. Для выбора версии клиент после коннекта выполняет команду 'set search_path to version_XYZ,data';
Мы используем MSSQL, поэтому топикстартеру не поможет, но все же
Мы используем вариант 1 в паре с продуктом Red Gate Source Control. Выделенные базы (у каждого своя) он тоже поддерживает, нам просто неудобно. Коммитимся в SVN, git тоже поддерживает, но не полностью (не позволяет сделать merge-скрипты для накатывания на бой генерируем скрипты между ревизиями. Для maven, как уже отмечали, есть плагин, который позволяет автоматизировать сборку, но мб у нас не тот плагин, но им неудобно пользоваться - скрипты должны быть названы ###_название файла, где ### - порядковый номер, и он помнит, что накатывал, что нет. Скрипты редгейта во-первых хранятся в его папках, во-вторых нельзя управлять названием, так что деплоймент идет вручную, пока всем лень автоматизировать переименование
Вариант 2 ок, но мне кажется неудобным постоянно пересоздавать базу с заливкой данных и тд. Особенно, когда надо тестировать производительность. В этом плане редгейт очень помогает - ревизию легко откатить
Вариант 3, конечно, тоже имеет право на существование, но поддерживать такой скрипт очень сложно
Мы используем вариант 1 в паре с продуктом Red Gate Source Control. Выделенные базы (у каждого своя) он тоже поддерживает, нам просто неудобно. Коммитимся в SVN, git тоже поддерживает, но не полностью (не позволяет сделать merge-скрипты для накатывания на бой генерируем скрипты между ревизиями. Для maven, как уже отмечали, есть плагин, который позволяет автоматизировать сборку, но мб у нас не тот плагин, но им неудобно пользоваться - скрипты должны быть названы ###_название файла, где ### - порядковый номер, и он помнит, что накатывал, что нет. Скрипты редгейта во-первых хранятся в его папках, во-вторых нельзя управлять названием, так что деплоймент идет вручную, пока всем лень автоматизировать переименование
Вариант 2 ок, но мне кажется неудобным постоянно пересоздавать базу с заливкой данных и тд. Особенно, когда надо тестировать производительность. В этом плане редгейт очень помогает - ревизию легко откатить
Вариант 3, конечно, тоже имеет право на существование, но поддерживать такой скрипт очень сложно
Расскажите как осуществляется совместная разработка бд.web page , та же фигня есть и для других языков.
я работал и с вариантом 2, и с 3
лично мне 3 больше нравился, т.к. косяков ГОРАЗДО меньше возникало.
через много лет разработки вариант 2 может привести пздц куда. (яркий пример - смена версии субд, один из старых скриптов на новой версии работал не как надо в зависимости от настроек субд, в итоге часть новых клиентов словило баг, были потеряны данные и куча нервов)
ещё вариант - пользоваться ормом, и хранить схему - этот вариант близок к третьему.
лично мне 3 больше нравился, т.к. косяков ГОРАЗДО меньше возникало.
через много лет разработки вариант 2 может привести пздц куда. (яркий пример - смена версии субд, один из старых скриптов на новой версии работал не как надо в зависимости от настроек субд, в итоге часть новых клиентов словило баг, были потеряны данные и куча нервов)
ещё вариант - пользоваться ормом, и хранить схему - этот вариант близок к третьему.
За создание вещей в базе отвечают скрипты, скармливаемые в sqlplus общим для всех инсталлятором.
Все изменения кроме совсем маленьких, про которые ты точно знаешь что никто не заметил, оформляются в отдельный 0037-tables-update.sql скрипт.
Скрипты, натурально, лежат в системе контроля версий.
Исполнение их по очереди с самого начала, или с того, который был последний исполнен для данной базы, по идее должно работать (а если не работает, то все долго пинают ногами того, кто всё сломал!). Общий для всех инсталлер помнит какие скрипты он проинсталлил, и даже помнит их ша1 хэш и переинсталлирует изменённые (типа если нужно записать в табличку всякие дефолтные значения, то лучше WNEVER SQL ERROR CONTINUE в начале, потом инсерты, и поправить основной скрипт, чем создавать апдейтящие).
Все изменения кроме совсем маленьких, про которые ты точно знаешь что никто не заметил, оформляются в отдельный 0037-tables-update.sql скрипт.
Скрипты, натурально, лежат в системе контроля версий.
Исполнение их по очереди с самого начала, или с того, который был последний исполнен для данной базы, по идее должно работать (а если не работает, то все долго пинают ногами того, кто всё сломал!). Общий для всех инсталлер помнит какие скрипты он проинсталлил, и даже помнит их ша1 хэш и переинсталлирует изменённые (типа если нужно записать в табличку всякие дефолтные значения, то лучше WNEVER SQL ERROR CONTINUE в начале, потом инсерты, и поправить основной скрипт, чем создавать апдейтящие).
Оставить комментарий
nstrukov
Здравствуйте.Расскажите как осуществляется совместная разработка бд.
Дано: 5 разработчиков создают веб-приложение, использующее постгрес. Как им взаимодействовать друг с другом?
Мне видятся такие варианты:
1. Все подключаются к одной development базе, и работают с ней. Когда один разработчик сломал что-либо в базе, это может повлиять на других. Остальные будут простаивать. Не годится.
2. У каждого своя база. DDL всех таблиц, скрипты создающие хранимые процедуры, и представления хранятся в отдельных файлах. Скрипт вставки данных тоже в отдельном файле. Файлы лежат под свн.
Тут у меня вопрос, что делать с этими файлами дальше?
Создаем shell скрпит для накатывания всех скриптов через psql в нужной последовательности(учитывая то, что один вьюшник может использовать другой, и они должны создаться в соответствии с очередностью).
Когда разработка закончена все скрипты коммитсятся.
Создаем production базу, накатываем на нее скрипты. Клиент начинает вбивать реальные конфедециальные данные, и допустим что дамп этой production базы нам делать уже нельзя. Выявляется баг. Для воспроизведения его на базах разработчиков из production базы создаем дамп только тех данных,которые необходимы для воспроизвдения бага.
Вставляем эти данные на development базы разработчиков. Они правят структуру бд, хранимые процедуры, представления, и коммитят измененные файлы. Теперь у нас есть некоторое количество скриптов, которые надо накатить на production базу. Идем и накатываем вручную нужные файлы.
3. То-же что и 2, но все ddl, процедуры и вьюшникик хранятся в одном большом файле. Так что накатываем всегда все что есть.
Не слишком ли муторные получаются варианты 2 и 3? Можно ли что-то придумать для облегчения жизни?
Я конечно нагуглил liquibase и другие вещи. Но, хотелось бы услышать совет опытных людей.
Спасибо.