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

1. Автоматическое
версионирование
и релиз баз данных
...для умников =)

2. Попробуем найти ответы на следующие вопросы:
➲ Зачем нужно автоматизировать процесс релиза
изменений в БД?
➲ Зачем нужна изоляция personal / dev / test / staging
/ production окружений?
➲ Зачем нужен continious integration процесс?
(сломал-увидел-починил)
➲ Как сделать процесс внесения изменений в
структуру БД предсказуемым?
➲ Как полноценно включить БД в continious
integration процесс?
➲ Как поддерживать синхронизацию приложения и
БД на всех окружениях?

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

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

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

6. Hello. Am I at the office?!
Certainly I am. I sleep on
the operating table!
Как сделать процесс внесения
изменений в структуру БД
предсказуемым?

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

9. Модель слияния «под релиз»
(ad hoc merging model)
➲ Эта модель разработки позволяет небольшим командам разработчиков
вносить изменения в одну и ту же целевую БД, при этом каждый из них
работает со своим изолированным экземпляром БД.
➲ Поскольку разработчики работают с личной БД они могут проводить отладку
своих изменений в изоляции.
➲ Не нужно вносить никаких ручных правок. Достаточно по завершению
разработки фичи сделать diff между рабочей и целевой БД и получить SQL с
изменениями.
➲ Велика вероятность конфликтов слияния изменений, поскольку разработчики
синхронизируют свои изменения с одной и той же целевой БД. Если
разработчики внесут изменения в один и тот же объект, о велика вероятность
что эти изменения будут бесследно потеряны во время синхронизации.
➲ Повышаются требования по координации слияний в целевую БД, их
периодичность должна быть адекватна интенсивности вносимых изменений.
➲ Нет управления версиями на уровне объектов БД. Если был обнаружен баг, то
становится очень сложно определить что именно привело к его возникновению.
Кроме того операция отката БД на предыдущую версию без ручного
вмешательства будет означать потерю всех изменений текущего релиза.

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

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

13. Оффлайн модель разработки
➲ Прямое редактирование скриптов, которые находятся под системой
контроля версий в некоторых случаях может быть преимуществом (привет
унылым клиентам TFS, VSS).
➲ Этот процесс уменьшает вероятность одновременного редактирования
одного и того же скрипта в большей степени чем в предыдущей модели.
➲ Продвинутые SQL diff-инструменты типа SQL Compare 6 Professional
автоматически определяет последовательность выполнения этих скриптов на
целевой БД принимая во внимание их связи.
➲ Отсутствует немедленная проверка изменений, поскольку они вначале должны
быть внесены в скрипт, а уже потом на тестовую БД.
➲ Для того чтобы проверить изменения их нужно применить к тестовой БД, что
добавляет дополнительный шаг.

14. Модель инкрементных изменений
(database migrations)
SQL-based db migrator DSL-based db migrator

15. RoundhousE db versioning tools
(part of the ChuckNorrisFramework)
➲ Name: Chuck Norris
➲ Email:
chucknorrisframework@googlegroups.co
m
➲ Website:
http://groups.google.com/group/chucknor
risframework
➲ Location: Chuck is everywhere
➲ Project: https://github.com/chucknorris/
roundhouse

16. Основные возможности RoundhousE
➲ Поддерживает Microsoft SQL Server, Oracle,
Access
➲ MySQL объявлен как alpha (моя реализация,
которая была обкатана на проекте
TravelConfirm)
➲ Заявлена поддержка PostgreSQL, SQLite
➲ Использует SQL для миграций БД
➲ Рализована на .NET, использует NHibernate
(могу портировать на другую СУБД или на
Mono/Linux/Mac OS X)
➲ Open source, лицензирована под Apache 2.0

17. Уникальные возможности RoundhousE
➲ Обладает достаточно умным поведением
➲ В большей степени дружественна к DBA чем другие SQL-
based миграторы
➲ Освобождает от написания патчей/миграций для stateless
скриптов
➲ Все скрипты разделяет на OneTime, AnyTime, Everytime
➲ Поддерживает скрипты, которые зависят от окружения
➲ Крайне рекомендована проектам с большим количеством
процедур, функций и представлений
➲ Вместо одного каталога со свалкой миграций их несколько
— baseline, up, functions, procedures, functions
➲ Подробное логирование процесса миграции БД
➲ Подробная регистрация успешных и неудачных миграций

18. Running RoundhousE v0.8.0.305 against (local) - TestRoundhousE.
Looking in C:coderoundhousecode_dropsampledeployment..dbSQLServerTestRoundhousE 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:coderoundhousecode_dropsampledeployment_BuildInfo.xml using //buildInfo/version.
Found version 0.8.0.305 from C:coderoundhousecode_dropsampledeployment_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.

19. ==================================================
Migration Scripts
==================================================
Looking for Update scripts in
"C:coderoundhousecode_dropsampledeployment..dbSQLServerTestRoundhousEup". 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:coderoundhousecode_dropsampledeployment..dbSQLServerTestRoundhousErunFirstAfte
rUp".
--------------------------------------------------
--------------------------------------------------
Looking for Function scripts in
"C:coderoundhousecode_dropsampledeployment..dbSQLServerTestRoundhousEfunctions".
--------------------------------------------------
Running ufn_GetDate.sql on (local) - TestRoundhousE.
--------------------------------------------------
Looking for View scripts in
"C:coderoundhousecode_dropsampledeployment..dbSQLServerTestRoundhousEviews".
--------------------------------------------------
Running vw_Dude.sql on (local) - TestRoundhousE.
--------------------------------------------------

20. Looking for Stored Procedure scripts in
"C:coderoundhousecode_dropsampledeployment..dbSQLServerTestRoundhousEsprocs".
--------------------------------------------------
Running usp_GetDate.sql on (local) - TestRoundhousE.
Running usp_SelectTimmy.sql on (local) - TestRoundhousE.
--------------------------------------------------
Looking for Run after Other Anytime Scripts scripts in
"C:coderoundhousecode_dropsampledeployment..dbSQLServerTestRoundhousErunAfterOt
herAnyTimeScripts".
--------------------------------------------------
Running createFiveItems.sql on (local) - TestRoundhousE.
--------------------------------------------------
Looking for Permission scripts in
"C:coderoundhousecode_dropsampledeployment..dbSQLServerTestRoundhousEpermissions
". 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.

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

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

23. Вопросы?
31337