TOC
После рассмотрения трёх правил и создания базиса, вся команда может работать с базой данных, базис которой безопасно расположен в репозитории контроля версий. Наступит день когда команде предстоит изменить схему. Каждое изменение приводит к новой версии базы данных. В моем подходе, скрипты базиса создали таблицу журнала изменений БД, чтобы отслеживать эти изменения.
Под термином “изменение”, я имею в виду изменения в таблице, индексе, ключе, ограничении или любом другом объекте, который определяется при помощи DDL, за исключением вьюшек, хранимых процедур и функций. Я работаю с этими объектами по-другому, и мы рассмотрим работу с ними, в следующем посте. Я также включаю в скрипты базиса любые изменения статических данных в скрипты модификации.
Данный текст явлется переводом. Оригинал по ссылке
#Альтернативы
Перед тем как показать пример я хотел бы отметить, что существует множество способов управления изменениями в базах данных и механизмов миграции. Фил Хаак описывает свои идемпотентные скрипты в статье Пуленепробиваемые Sql скрипты изменения использующие INFORMATION_VIEWS. Эллиот Смит и Роб Николс являются database agnostic-ами (без привязки к конкретной БД) при помощи Ruby Migrations. Если знаете другие хорошие статьи, пожалуйста, размещайте ссылки в комментариях. Опять же, задача состоит в управлении изменениями вашего проекта по возможнсти самым простым образом.
#Пример, пожалуйста
Команда только что определила базис базы данных, которая включает таблицу Customers, но теперь хочет добавить новый столбец для хранения размера обуви клиента. Они также определили OrderState таблицу, которая является - LookUp таблицей включающей значения ‘Open’, и ‘Shipped’, сейчас нужно расширить новым значением ‘Canceled’. Для этого команда должна создать скрипт изменения схемы, который выглядит следующим образом. Заметьте, что я могу включить в один скрипт столько изменений сколько необходимо.
:::SQL
#Файл: sc.01.00.0001.sql
ALTER TABLE Customer
ADD SHOESIZE INT NOT NULL DEFAULT 0
GO
INSERT INTO OrderStates
(OrderStateID, OrderState)
VALUES (3, 'Cancelled')
GO
Тот кто пишет этот скрипт, также будет проверять его с различными тестовыми данными,а затем зафиксирует в системе контроля версий. После этого изменения схемы официально опубликованы. Изменения схемы начнут появляться в рабочем окружении разработчиков, как только они получат обновления из системы контроля версий, а также на тестовых машинах, как только новые версии получат QA и после чего продвинется далее.
Автоматизация обновления базы данных это хорошо, так что автоматизируйте всё настолько безжалостно, насколько это возможно. В идеале, разработчик, тестировщик, или пользователь должен иметь возможность запустить инструмент, который проверит версию схемы базы данных в таблице SchemaChangeLog, сравнит эту версию с доступными обновлениями в скриптах изменения в файловой системе. Сортировки файлов по имени будет достаточно что-бы обеспечить версионирование, используя методы описаны здесь. Интерфейс командной строки в этом случае для утилиты предпочтительнее потому, что вы можете использовать её в скриптах сборки, на машинах разработчиков и при установке пакетов. Вы всегда можете обернуть этот инструмент в GUI, что-бы сделать его более простым в использовании. Вот пример работы такого инструмента обновления схемы (некоторые записи удалены для краткости):
:::
Connected to server .
Connected to database xyz
Host: SALLEN2 User: xyz\sallen
Microsoft SQL Server 2005 - 9.00.3054.00 (Intel X86)
Schema history:
05.00.0000 initial-install on Dec 13 2007 11:26AM
05.00.0001 sc.05.00.0001.sql on Dec 13 2007 11:26AM
05.00.0002 sc.05.00.0002.sql on Dec 13 2007 11:26AM
...
05.00.0012 sc.05.00.0012.sql on Dec 13 2007 11:26AM
05.01.0000 sc.05.01.0000.sql on Dec 13 2007 11:26AM
05.01.0001 sc.05.01.0001.sql on Dec 13 2007 11:26AM
...
05.01.0019 sc.05.01.0019.sql on Dec 13 2007 11:26AM
Current version:
05.01.0019
The following updates are available:
sc.05.01.0020.sql
sc.05.01.0021.sql
После того, как разработчик запустит изменения схемы, он должен увидеть следующую информацию в журнале изменений схемы:
#Правила изменения схемы и советы
После того, как сценарий опубликован в систему контроля версий, он не может быть изменен! После того, как кто-то обновит свою базу данных с помощью скриптов обновления, они никогда не должны запускаться на той же базе данных.
Ответственность обновления таблицы SchemaChangeLog должен нести инструмент, который применяет обновления. Таким образом, инструмент может обеспечить успешное выполнение скриптов перед записью обновления в журнале изменений.
Всегда создайте бэкапы баз данных продакшена до применения скрипта изменения. Если во время выполнения скрипта изменения произойдёт сбой с ошибкой, вы можете по крайней мере вернуть базу данных обратно в рабочем состоянии.
Некоторые люди переживают, что произойдет, если несколько разработчиков будут работатать над скриптами изменения одновременно. К счастью, репозиторий системы контроля версий является отличным посредником. Я не могу добавить скрипт обновления с тем же именем, что и ваш скрипт обновления - мне придется увеличить номер моей версии, если вы опередите меня при коммите на несколько секунд.
Конечно, изменения касаются не только об изменениях схемы БД. Вы также должны писать код для переноса данных. Например, если по какой-то причине вы перенесли столбец ShoeSize из таблицы Customers в таблицу CustomerDetails, скрипт обновления должен будет также переместить и данные. Работа с данными зачастую наиболее сложная часть скриптов изменения и они нуждаются больше всего в тестировании.
#Резюме
Управление изменениями базы данных дает очень много преимуществ. Поскольку скрипты изменения схемы находятся в системе управления версиями, вы можете воссоздать вашу базу данных, и её состояние в любой момент времени. Клиент сообщил об ошибке на сборке 3.1.5.6723? Получите исходный код с номером версии и резверните базис БД, а затем все сценарии изменения схемы включеные в эту версию. Теперь у вас есть та же база данных и гораздо больше шансов воспроизвести ошибку. Кроме того, изменения переходят от разработки в тестирование, и в конечном итоге в продакшен последовательно, воспроизводимо и в установленном порядке.
Я пропустил довольно много мелких деталей, но я надеюсь, что вы получили общее представление. Я использовал этот подход в течение многих лет, и он хорошо работал. Тем не менее, я чувствую, что подход не самый оптимальный и я постоянно ищу пути улучшения. Обратная связь приветствуется. Так что вы думаете по этому поводу?
Работаю над следующим - управление вью-шками и хранимыми процедурами.
comments powered by Disqus