Автоматическоеверсионированиеи релиз баз данных

...для умников =)

Попробуем найти ответы на следующие вопросы:

➲ Зачем нужно автоматизироватьавтоматизировать процесс релиза изменений в БД?

➲ Зачем нужна изоляция personal / dev / test / staging personal / dev / test / staging / production/ production окружений?

➲ Зачем нужен continious integration continious integration процесс?(сломал-увидел-починил)➲ Как сделать процесс внесения изменений внесения изменений в

структуру БД предсказуемым?➲ Как полноценно включить БД в continious continious

integration integration процесс?➲ Как поддерживать синхронизацию приложения синхронизацию приложения и

БД на всех окружениях?

Зачем нужно автоматизироватьавтоматизировать процесс релиза изменений в БД?

Зачем нужна изоляция изоляция personal

dev test

staging production

окружений?

Зачем нужен continious integration процесс?(сломал-увидел-починил)

Как сделать процесс внесения внесения измененийизменений в структуру БД

предсказуемым?

Hello. Am I at the office?! Certainly I am. I sleep on the operating table!

Как поддерживать синхронизацию синхронизацию приложения и БДна всех окружениях?

Модель слияния «под релиз» (ad hoc merging model)➲ Эта модель разработки позволяет небольшим командам разработчиков

вносить изменения в одну и ту же целевую БД, при этом каждый из них работает со своим изолированным экземпляром БД.

➲ Поскольку разработчики работают с личной БД они могут проводить отладку своих изменений в изоляции.

➲ Не нужно вносить никаких ручных правок. Достаточно по завершению разработки фичи сделать diff между рабочей и целевой БД и получить SQL с изменениями.

➲ Велика вероятность конфликтов слияния изменений, поскольку разработчики синхронизируют свои изменения с одной и той же целевой БД. Если разработчики внесут изменения в один и тот же объект, о велика вероятность что эти изменения будут бесследно потеряны во время синхронизации.

➲ Повышаются требования по координации слияний в целевую БД, их периодичность должна быть адекватна интенсивности вносимых изменений.

➲ Нет управления версиями на уровне объектов БД. Если был обнаружен баг, то становится очень сложно определить что именно привело к его возникновению. Кроме того операция отката БД на предыдущую версию без ручного вмешательства будет означать потерю всех изменений текущего релиза.

Версионировние и слияние на уровне объектов схемы БД➲ Каждый индивидуальный объект схемы БД наховится в виде отдельного скрипта

в системе контроля версий, что позволяет прослеживать историю изменений конкретного объекта.

➲ Разработчики как и в предыдущей модели работают напрямую с живой БД, что упрощает отладку изменений.

➲ Можно использовать некоторые возможности системы контроля для управления проектом. Например во время коммита оставлять комментарии и прочую информацию на уровне отдельных объектов схемы БД.

➲ Можно устанавливать блокировку изменений на уровне отдельных скриптов во время внесения изменений, если данные возможности есть у системы контроля версий.

➲ В случае параллельной разработки конфликты слияний разрешаются намного проще за счет того что изменения носят мелкодисперсный характер.

➲ Использование этой модели накладывает большую дисциплинированность и более формальный подход, что может быть неудобно разработчикам, которые работают в более динамичном режиме.

ОффлайнОффлайн модель разработки

Оффлайн модель разработки➲ Прямое редактирование скриптов, которые находятся под системой

контроля версий в некоторых случаях может быть преимуществом (привет унылым клиентам TFS, VSS).

➲ Этот процесс уменьшает вероятность одновременного редактирования одного и того же скрипта в большей степени чем в предыдущей модели.

➲ Продвинутые SQL diff-инструменты типа SQL Compare 6 Professional автоматически определяет последовательность выполнения этих скриптов на целевой БД принимая во внимание их связи.

➲ Отсутствует немедленная проверка изменений, поскольку они вначале должны быть внесены в скрипт, а уже потом на тестовую БД.

➲ Для того чтобы проверить изменения их нужно применить к тестовой БД, что добавляет дополнительный шаг.

Модель инкрементных изменений (database migrations)

SQL-based db migrator DSL-based db migrator

RoundhousE db versioning tools(part of the ChuckNorrisFramework)

➲ Name: Name: Chuck Norris➲ Email: Email:

chucknorrisframework@googlegroups.com

➲ Website: Website: http://groups.google.com/group/chucknorrisframework

➲ Location: Location: Chuck is everywhere ➲ Project: Project: https://github.com/chucknorris/ roundhouse

Основные возможности RoundhousE

➲ Поддерживает Microsoft SQL Server, Oracle, Access

➲ MySQL объявлен как alpha (моя реализация, которая была обкатана на проекте TravelConfirm)

➲ Заявлена поддержка PostgreSQL, SQLite➲ Использует SQL для миграций БД➲ Рализована на .NET, использует NHibernate

(могу портировать на другую СУБД или на Mono/Linux/Mac OS X)

➲ Open source, лицензирована под Apache 2.0

Уникальные возможности RoundhousE

➲ Обладает достаточно умным поведением➲ В большей степени дружественна к DBA чем другие SQL-

based миграторы➲ Освобождает от написания патчей/миграций для stateless

скриптов➲ Все скрипты разделяет на OneTime, AnyTime, Everytime➲ Поддерживает скрипты, которые зависят от окружения➲ Крайне рекомендована проектам с большим количеством

процедур, функций и представлений➲ Вместо одного каталога со свалкой миграций их несколько

— baseline, up, functions, procedures, functions➲ Подробное логирование процесса миграции БД➲ Подробная регистрация успешных и неудачных миграций

Running RoundhousE v0.8.0.305 against (local) - TestRoundhousE.Looking in C:\code\roundhouse\code_drop\sample\deployment\..\db\SQLServer\TestRoundhousE for scripts to run.Please press enter when ready to kick...==================================================Setup, Backup, Create/Restore/Drop==================================================Creating TestRoundhousE database on (local) server if it doesn't exist.==================================================RoundhousE Structure================================================== Running database type specific tasks. Creating RoundhousE schema if it doesn't exist. Creating [Version] table if it doesn't exist. Creating [ScriptsRun] table if it doesn't exist. Creating [ScriptsRunErrors] table if it doesn't exist.==================================================Versioning================================================== Attempting to resolve version from C:\code\roundhouse\code_drop\sample\deployment\_BuildInfo.xml using //buildInfo/version. Found version 0.8.0.305 from C:\code\roundhouse\code_drop\sample\deployment\_BuildInfo.xml. Migrating TestRoundhousE from version 0 to 0.8.0.305. Versioning TestRoundhousE database with version 0.8.0.305 based on http://roundhouse.googlecode.com/svn.

==================================================Migration Scripts==================================================Looking for Update scripts in "C:\code\roundhouse\code_drop\sample\deployment\..\db\SQLServer\TestRoundhousE\up". These should be one time only scripts.-------------------------------------------------- Running 0001_CreateTables.sql on (local) - TestRoundhousE. Running 0001_CreateTables_NH.sql on (local) - TestRoundhousE. Running 0002_ChangeTable.sql on (local) - TestRoundhousE. Running 0003_TestBatchSplitter.sql on (local) - TestRoundhousE.--------------------------------------------------Looking for Run First After Update scripts in "C:\code\roundhouse\code_drop\sample\deployment\..\db\SQLServer\TestRoundhousE\runFirstAfterUp".----------------------------------------------------------------------------------------------------Looking for Function scripts in "C:\code\roundhouse\code_drop\sample\deployment\..\db\SQLServer\TestRoundhousE\functions".-------------------------------------------------- Running ufn_GetDate.sql on (local) - TestRoundhousE.--------------------------------------------------Looking for View scripts in "C:\code\roundhouse\code_drop\sample\deployment\..\db\SQLServer\TestRoundhousE\views".-------------------------------------------------- Running vw_Dude.sql on (local) - TestRoundhousE.--------------------------------------------------

Looking for Stored Procedure scripts in "C:\code\roundhouse\code_drop\sample\deployment\..\db\SQLServer\TestRoundhousE\sprocs".-------------------------------------------------- Running usp_GetDate.sql on (local) - TestRoundhousE. Running usp_SelectTimmy.sql on (local) - TestRoundhousE.--------------------------------------------------Looking for Run after Other Anytime Scripts scripts in "C:\code\roundhouse\code_drop\sample\deployment\..\db\SQLServer\TestRoundhousE\runAfterOtherAnyTimeScripts".-------------------------------------------------- Running createFiveItems.sql on (local) - TestRoundhousE.--------------------------------------------------Looking for Permission scripts in "C:\code\roundhouse\code_drop\sample\deployment\..\db\SQLServer\TestRoundhousE\permissions". These scripts will run every time.-------------------------------------------------- Running 0001_AppRole.sql on (local) - TestRoundhousE. Running 0002_AppReadOnlyRole.sql on (local) - TestRoundhousE. Running 0003_AppPermissionsWiring.sql on (local) - TestRoundhousE. LOCAL.GrantRobDataReaderDataWriterPermissions.ENV.sql is an environment file. We are in the LOCAL environment. This will run based on this check. Running LOCAL.GrantRobDataReaderDataWriterPermissions.ENV.sql on (local) - TestRoundhousE. TEST.GrantRobDataReaderDataWriterPermissions.ENV.sql is an environment file. We are in the LOCAL environment. This will NOT run based on this check. Skipped TEST.GrantRobDataReaderDataWriterPermissions.ENV.sql - No changes were found to run.

RoundhousE ведет подробную регистрацию SQL-скриптов

RoundhousE отслеживает ситуации когда OneTime скрипт был обновлен

Вопросы?

31337