Автоматическоеверсионированиеи релиз баз данных
...для умников =)
Попробуем найти ответы на следующие вопросы:
➲ Зачем нужно автоматизироватьавтоматизировать процесс релиза изменений в БД?
➲ Зачем нужна изоляция 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:
➲ 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
Top Related