Комментарии 11
Если у вас в разных средах разные данные, то с большой долей вероятности скрипт конвертации, отлаженный на тестовой среде, что-то сделает не так и/или упадёт в UAT/продакшене. Плавали, знаем.
Согласен, такое возможно. В данном контексте разговор больше об отличиях в структурах данных, а точнее инфраструктуре (tablespaces, database links, directory, schema name etc etc).
В случае данный применять условную компиляцию тоже можно… но это уже совсем другая история, как говорится.
И да, хотя бы UAT крайне стоит организовывать максимально подобным к Prod-окружению. Тем более что в ряде организаций у вас на Prod не будет доступа, даже r\o (к сожалению).
В случае данный применять условную компиляцию тоже можно… но это уже совсем другая история, как говорится.
И да, хотя бы UAT крайне стоит организовывать максимально подобным к Prod-окружению. Тем более что в ряде организаций у вас на Prod не будет доступа, даже r\o (к сожалению).
А я вот люблю невозможное — когда SQL скрипты максимально независимы даже не от окружения родной СУБД, а от СУБД в принципе. Но тут макро-подстановка переменных уже не спасет, приходится в деплой-скрипты писать на активном языке, парсая исходные SQL и заменой и регулярными выражениями. Воистину, в аду для перфекционистов просто немного неровно стоят щербатые котлы…
Извините, не удержался.
[режим простых истин on] Делая приложение независимым от СУБД вы либо теряете бенефиты, которые предлагает та или иная СУБД (перфоманс как следствие) либо, погружаетесь в условную компиляцию или уровень абстракций от СУБД, пишите много кода, чтобы ваше приложение одинаково хорошо работало с _нексколькими_ выбранными СУБД. [режим простых истин off]
Хотя, признаю, бывают (редкие) случаи когда БД испольуется как черный ящик «тупо для хранения» и к СУБД возлагается минимум специфических требований.
[режим простых истин on] Делая приложение независимым от СУБД вы либо теряете бенефиты, которые предлагает та или иная СУБД (перфоманс как следствие) либо, погружаетесь в условную компиляцию или уровень абстракций от СУБД, пишите много кода, чтобы ваше приложение одинаково хорошо работало с _нексколькими_ выбранными СУБД. [режим простых истин off]
Хотя, признаю, бывают (редкие) случаи когда БД испольуется как черный ящик «тупо для хранения» и к СУБД возлагается минимум специфических требований.
Есть продукты, например финансовые и банковские, которые должны иметь альтернативные СУБД и работать не хуже на них. Это вопрос покупки дорогостоящих лицензий и интеграции с уже написанной сложной инфраструктурой (то есть — от нас не зависит в общем то). А вести два-три скрипта загрузки по 100 таблиц и синхронно их менять — нужно иметь очень крепкие нервы. Поэтому, проще придумать свое расширение синтаксиса SQL, которое перед загрузкой в определенную СУБД нужно «откомпилировать» своей специальной программой. По сути сделать такой компилятор — это дешевле, чем вести версии для разных систем и избавляет от человеческого фактора. После компиляции SQL уже жестко привязан к СУБД с учетом оптимизации и платформенных особенностей, без которых, как Вы правильно говорите, невозможно сделать хорошего приложения. Чем-то конечно нужно будет жертвовать, например, мы еще не дошли до того, чтобы в разных СУБД было разное кол-во таблиц или связей в зависимости от особенностей.
No offence, я лишь вторю Кайту, в той части, где он говорит про должное понимание особенностей (и разницы этих особенностей) субд: это не только синтаксис, это куда более важная разница в реализации MVCC которая [потенциально] ведет к необходимости по-разному реализовывать логику самого приложения.
Видимо вы пошли по второму пути, где учитываете эти особенности, оборотной стороной этой медали миритесь с возросшей сложностью.
Что за продукт, если не секрет, к которому такие требования?
Видимо вы пошли по второму пути, где учитываете эти особенности, оборотной стороной этой медали миритесь с возросшей сложностью.
Что за продукт, если не секрет, к которому такие требования?
Мне доводилось три проекта делать подобным методом, систему сбора и консолидации данных с телеметрии, поддержку принятия решений для debt-collection, и сейчас консультирую самый простой из них — «Кампус» для ВУЗа (КПИ). Использовались соответственно: Informix+Interbase+DB/2 (давно было), MsSQL+Oracle, MsSQL+MySQL. Компилятор не так сложен, 5кб регулярных выражений. В предыдущих проектах компиляторы были огромными — это правда, но только по недостатку опыта.
Хороший паттерн, используем, плюсую.
На текущем проекте пошли еще дальше и активно юзаем переменные окружения — по аналогии с приведенным выше, это как если бы все дефайны заполнялись из них. Это удобно, например для того, когда один application server фактически шарит между собой несколько окружений (dev, qa, uat) и нужно передавать приложениям разных окружений начальные коннективити данные (сервер, инстанс, схема) + если у вас фактически в одном инстансе крутится несколько разных окружений (dev, qa, uat). Переменные окружения в этом случае, добавляя гибкости, выполняют роль профиля, который легко подсосать и приложениям, и легко передать в деплоймент скрипт (через параметры) который развернет базу. Таких профилей создается по количеству энвайронментов, выбор происходит соурсингом соответствующего .sh файла (например удобно через менюшку в ~$APPLICATION_USER/.profile на этапе логина + shell альясы типа setdev2).
Из других deployment-related полезностей — «обкатка» в CI среде патч- и ролбек- скриптов (которыми во время релиза докатывается/откатывается prod база). Для этого настраивается отдельный энвайромент, на котором автоматом (по шедулеру, по коммиту) сначала разворачивается последний прод клон, потом применяется набор патчей для разрабатываемой новой версии, потом применяются ролбеки и снова патчи (back-and-forth, back-and-forth) — т.о. гарантируется некая повторяемость, консистентность и атомарность релиза в части изменения БД.
На текущем проекте пошли еще дальше и активно юзаем переменные окружения — по аналогии с приведенным выше, это как если бы все дефайны заполнялись из них. Это удобно, например для того, когда один application server фактически шарит между собой несколько окружений (dev, qa, uat) и нужно передавать приложениям разных окружений начальные коннективити данные (сервер, инстанс, схема) + если у вас фактически в одном инстансе крутится несколько разных окружений (dev, qa, uat). Переменные окружения в этом случае, добавляя гибкости, выполняют роль профиля, который легко подсосать и приложениям, и легко передать в деплоймент скрипт (через параметры) который развернет базу. Таких профилей создается по количеству энвайронментов, выбор происходит соурсингом соответствующего .sh файла (например удобно через менюшку в ~$APPLICATION_USER/.profile на этапе логина + shell альясы типа setdev2).
Из других deployment-related полезностей — «обкатка» в CI среде патч- и ролбек- скриптов (которыми во время релиза докатывается/откатывается prod база). Для этого настраивается отдельный энвайромент, на котором автоматом (по шедулеру, по коммиту) сначала разворачивается последний прод клон, потом применяется набор патчей для разрабатываемой новой версии, потом применяются ролбеки и снова патчи (back-and-forth, back-and-forth) — т.о. гарантируется некая повторяемость, консистентность и атомарность релиза в части изменения БД.
Да, CI среда для базы — давно моя «мечта», даже скрипты для этого подготовил, но нам постоянно не хватает по мнению менеджмента «свободного» окружения для этого и куча бюрократической волокиты с DBA- командой, которая поддерживает наши сервера и от них зависит настройка выгрузки прода. Но идея очень правильная, поддерживаю всеми руками и плюсую!
Окружений никогда не хватает, факт, и бюрократия доставляет, согласен. Поэтому я и упомянул идею когда один физический oracle инстанс шарится между разными окружениям. Например CI может быть на том же инстансе где у вас уже есть DEV, для разделения схем можно использовать суффиксы / префиксы — например HR_DEV1, HR_DEV2, HR_CI — три схемы в одном инстансе которые относятся к разным энвайроментам. ДБАшники могут и не заметить чита, их лишь надо попросить аккаунтов создать, а тейблспейсы для простоты поддержки можно заюзать существующие. Придется мириться правда (возможно) с некоторым даунгрейдом перформанса, но зато «в теле такая приятная гибкость образовалась» (с) :-)
По поводу выгрузки прода, совсем не обязательно каждый раз обновлять CI из свежеиспеченного физического дампа прода. Если предположить что структура прода между релизами не меняется (исключение — если quick fix выкатываете) то дамп можно сделать сразу после релиза, и потом его использовать вплоть до следующего релиза. Здесь исхожу из предположения, что данные, их свежесть, для обкатки не так важны.
А если подумать в сторону логического дампа, который требует только SCHEMA OWNER чтобы подропать все что было и пересоздать заново, то ДБАшники точно ничего не узнают :-)
Буду с интересом следить за следующими вашими статьями, пишите!
По поводу выгрузки прода, совсем не обязательно каждый раз обновлять CI из свежеиспеченного физического дампа прода. Если предположить что структура прода между релизами не меняется (исключение — если quick fix выкатываете) то дамп можно сделать сразу после релиза, и потом его использовать вплоть до следующего релиза. Здесь исхожу из предположения, что данные, их свежесть, для обкатки не так важны.
А если подумать в сторону логического дампа, который требует только SCHEMA OWNER чтобы подропать все что было и пересоздать заново, то ДБАшники точно ничего не узнают :-)
Буду с интересом следить за следующими вашими статьями, пишите!
Я для таких целей чаще использую ant/maven. На вход параметры либо через коммандную строку либо через properties-файл, внутри вызывается sqlplus / sqlcmd / mysql / psql / whatever предварительно заменив все плейсхолдеры параметрами из конфига. Иногда используется комбинированный подход — maven'ом/ant'ом формируется, то что у автора называется par_file на базе параметров командной строки / ввёдных в интерактивном режиме значений / whatever, затем просто вызываются всё те же sqlplus / sqlcmd… В этом случае можно запускать как через ant/maven, так и без них, что удобно как для CI, так и для production версии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делаем oracle deploy-скрипт независимым от окружения