SQL Change Master — I

Из истории вопроса

Прежде чем приступить к описанию программы, я бы хотел осветить сам вопрос работы с базой данных по гибким методологиям. Или лучше сказать итеративное развитие базы данных, когда изменения в базу вносятся тогда, когда они нужны. Когда база развивается одновременно с приложением и, по сути, идет модель Code First, тогда база отвечает потребностям кода, а не код старается подстроиться под базу.

Я думаю, что для большинства, вполне очевидно, что модель хранения данных, и модель работы с данными, это две слабо пересекающиеся модели. Еще было бы замечательно поделить это все на модели/структуры для чтения и модели/структуры для  записи. Но это отдельная огромная тема, которую я не готов раскрыть.

Итак, в начальных условиях у нас в идеале новый проект, green field, или как минимум еще не выпущенный в релиз (разработчики любят начинать все с нуля). Но ничто по большому счету не мешает применить практики итеративного обновления данных и для выпущенного проекта. Если вы используете у себя итеративную поставку, то почему база должна отличаться?

На тему подходов к разработке БД и хранению ее скриптов в системе контроля версий сломано немало копий. Многие крупные разработчики предлагают свои решения, как программные, так и организаторского плана. Хороший обзор получился у  Outcoldman’а, описываются основные подходы к решению обновления БД и хранению истории с помощью проектов от Microsoft, Red Gate, еще каких-то разработчиков. Есть у всех свои слабые и сильные стороны. Я, так же как и Outcoldman, придерживаюсь мнения, что надо писать собственные скрипты обновления и использовать либо готовые решения, либо самому написать простейшие управляющие вещи, по выполнению этих скриптов.

Я лично пробовал только итеративный подход с ручным написанием/генерацией скриптов и датабазные проекты от Микрософт в студии. Датабазные проекты меня не впечатлили, так как там отсутствуют очень важные в жизни вещи, как-то:

  • Миграция данных
  • Переименование через drop\create
  • Атомарность обновлений
  • Однозначное определение текущего состояния базы

Не секрет, что некоторые технологий от Микрософта направлены на создание вау-эффекта и годны только для демонстрации и создания простейших приложений не из области энтерпрайз. Я думаю, что датабазные проекты с генерацией скриптов разницы совсем не то, что необходимо в большинстве случаев.

Структура скриптов для итеративного обновления

Структура папок для итеративного обновления базы данных может выглядеть следующим образом:

  • Database
  • Schema Changes
  • Views
  • Stored Procedures
  • Functions
  • Triggers

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

Schema Changes – здесь содержаться все изменения структуры базы данных. Здесь же идет заполнение таблиц данными (если надо), здесь же идет удаление данных. О правилах и рекомендациях по составлению скриптов будет ниже.

Views – представления. Скрипты всегда должны выглядеть как для создания нового элемента. Если представление надо изменить, то меняется исходный файл.

Stored Procedures – хранимые процедуры для базы данных. Так же как и представления, могут свободно изменяться. Нет никаких ограничений и правил на название файлов.

Functions – функции. Неважно какого типа, скалярные, табличные – все здесь.

Triggers – триггеры. Я лично не одобряю их использование и вставил бы тут изображение stared dad, но если все же без них никуда, то складывать все триггеры в эту папку.

Правила и рекомендации по написанию скриптов

Самое важное правило:

СКРИПТЫ НЕЛЬЗЯ МЕНЯТЬ ПОСЛЕ ЗАНЕСЕНИЯ В СИСТЕМУ КОНТРОЛЯ ВЕРСИЙ!

Даже если вам надо только одну строчку дописать или еще что-то там сделать меленькое, надо создавать новый скрипт.

На этом правила заканчиваются, по сути, и идут только рекомендации.

Скрипты обновлений лучше всего оформлять в транзакции с режимом xact_abort. Т.е.

Если по-простому, то это нужно для моментально отката всех манипуляций несмотря на всякие Go в тексте.

Файлы скриптов надо именовать так, чтобы имена файлов упорядочивались по возрастанию. Т.е. можно начать с 001 и далее идти на увеличение. Можно использовать даты в духе 20110101.0101. Главное чтобы было просто и однозначно для всех в команде.

Рекомендую явно давать имена всем констрейнтам (constraints) в базе. Это вам пригодится при дальнейшем удалении или модификации их, так как можно будет точечно работать. Чуть больше работы при написании позволит вам не бить в дальнейшем «по площадям».

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

Возможности программы

Собственно теперь я расскажу, что же может программа.

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

Во-вторых, программа может обновлять базы пакетно и по различным настройкам окружения. Т.е. у вас есть несколько баз данных (base1, base2, etc) и несколько серверов (personal, dev, test, etc) и вы можете это все настроить в любых удобных конфигурациях и легко переключаться между ними.

Третьим пунктом идет возможность работы из консоли, для обновления баз данных. При создании окружения вы можете задать синоним к окружению и, передав его в качестве параметра, обновить базы. Удобно для Continuous Integration и для настройки команд в студии.

Последним пунктом идет возможность сохранения всех примененных скриптов в специальную базу данных мониторинга. Это может быть полезно в случае, когда вы разрабатываете приложение, которое ставит базу данных у клиента и хотите обновлять базу с помощью автоматики. Т.е. можно сделать сервис, который будет отдавать необходимые скрипты клиенту в зависимости от того, какая версия базы данных у него. Для этого не придется специально, руками, куда-то копировать и готовить скрипты или что-нибудь еще в таком духе. Вы ведь уже один раз поработали, написав скрипты, остальное может быть сделано и без вашего непосредственного участия!

Установка SQL Change Master

Программа полностью самодостаточна и распространяется по системе xcopy, если у вас есть .Net Framework 4. Никаких записей в реестр, системные файлы и все такое прочее. Можно поставить и удалить, перенести руками в любое место. Это является, с моей точки зрения, несомненным плюсом.

Программа не требует администраторских прав.

Программа так же извещает вас об обновлениях, если таковые появляются, и вы решаете, загружать их или нет.

Начало работы

Работа в графическом режиме

Для начала работы с программой, надо запустить ChangeController.exe

После этого вы увидите экран для создания настроек окружения.

Создание настроек окружения

 

Для создания нового окружения надо нажать на ссылку Add, после чего появятся дополнительные элементы управления, где можно будет ввести

  • Название окружения (Environment Name) – Это название для вас, для того чтобы сразу понять куда смотрят настройки для баз.
  • Короткое название (Alias) – это необязательное поле, но его надо заполнить, если вы хотите пользоваться программой из командной строки.

После заполнения необходимых данных надо подтвердить изменения (Confirm changes). После чего программа перенаправит вас на экран для создания служебной базы мониторинга, где будут храниться все примененные скрипты по обновлению базы и создании процедур, представления и так далее.

Данный шаг можно пропустить и перейти к заданию баз для обновления и папок со скриптами для мониторинга. Для этого надо нажать на Back to main operations. Программа перенесет вас на основной экран, где будет представлена основная информация о базах, за которыми следит программа. Номер версии базы, последняя возможная версия, дата последнего обновления, элементы управления.

Пока что вы увидите только пустой экран, где можно будет задать базы для отслеживания.

 

Создание базы для отслеживания

Чтобы сказать программе, какие базы данных ей надо отслеживать и с какими она будет работать, надо нажать на ссылку Add connection. После чего вы попадете на экран, где можно будет ввести все настройки для соединения с базой данных

  • Имя сервера
  • Название базы
  • Логин
  • Пароль
  • Таймаут соединения
  • Адрес до папки со скриптами обновления (можно вводить как полные так и относительные пути)

Тут же можно будет проверить правильность введенных данных. Если база данных не найдена, то программа предложить создать такую базу с настройками по умолчанию.

После того как вы решите, что же делать с базой, создать ее с помощью программы или же оставить все на совести разработчиков скриптов, можно возвращаться на главный экран. Настройки сохраняются автоматически при возвращении на основной рабочий экран.

Обновление базы данных

 

Так выглядит основной рабочий экран. Здесь выводятся все базы, которые внесены в выбранное окружение (в данном случае Development). Для каждой базы показывается

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

Элементы управления для каждой базы:

  • Лог обновления базы
  • Запуск обновлений
  • Обновление информации о базе
  • Редактирование свойств соединения и расположения скриптов
  • Удаление базы из окружения

Для запуска процесса обновления есть два способа:

  • Запускать обновление каждой базы отдельно
  • Запустить обновление для всех разом

При первом способе вам нужно будет нажать на зеленые треугольники для каждой записи, во втором способе достаточно будет нажать на Update my databases, чтобы все базы обновились до последней версии.

После отработки всех скриптов, можно будет посмотреть лог выполнения.

Если в процессе обновления базы возникают ошибки, то около значка просмотра логов, будет восклицательный знак. Сами действия, которые привели к ошибке, будут в логе подсвечены красным цветом.

Еще немного общей информации

Для переключения между окружениями надо просто нажать на имя окружения и программа перенесет вас на экран, где можно будет добавлять, удалять, переключаться между окружениями.

Настройка специальной базы для мониторинга осуществляется через ссылку Settings на главном экране программы.

Программа автоматически запоминает все настройки. Например, при повторном запуске, вы продолжите работать с тем окружением, с которым закончили в прошлый раз.

 

На этом пока все, продолжение в следующем выпуске. Будет рассказано, как работать в консоли, как настраивать студию для работы с приложением и еще кое-что.

Hard’n’heavy!

 

Оставить комментарий