Миграции схемы данных: расширение возможностей и опыт использования
8 июля 2015
Автор: Максим Мул
В конце 2014 года мы анонсировали модуль "Миграции схемы данных". В дальнейшем решение получило развитие, с которым мы и хотим поделиться. В начале расскажем о значимых новинках модуля и в конце статьи будут первые итоги использования модуля.
Расширение настроек модуля
Автоматические миграции на данный момент работают только с модулем "Информационные блоки". Теперь в настройках модуля можно указать какие виды сущностей модуля “Инфоблоки” попадают под синхронизацию.
К примеру, можно переносить между копиями проекта только инфоблоки, не учитывая их свойства и разделы. Переносить только свойства или разделы без инфоблоков нельзя.
Защита версии копии проекта
При переносе проекта с одной машины на другую получаются идентичные копии проектов с точки зрения модуля миграций и поэтому необходимо менять версию платформы у нового разработчика, что не всегда делалось и приводило к ошибкам в работе модуля. Для устранения человеческого фактора добавлена проверка на уникальность версии проекта в модуле миграций. При переходе в раздел "Версии платформ" система автоматически подсветит красным информацию о версии платформы.
Также, если не сменить версию проекта, то при попытке выполнить манипуляции с сущностями, которые находятся под автоматическими миграциями (как пример, добавление инфоблока), возникнет исключение в коде.
Кроме этого, была добавлена подпись для идентификации владельца копии проекта, что удобно при просмотре лога миграций и других отладочных действиях.
Расширенная информация о миграциях
Работа миграций на первых порах напоминала черный ящик без возможности узнать, что и когда менялось на проекте. Для удобства использования и "разбора полетов" был добавлен учет миграций и идентификаторов данных на всех копиях проекта.
В журнале изменений можно посмотреть список примененных миграций. В списке доступна информация о дате применения миграции, откуда она пришла, кто делал применение.
Также доступна более подробная информация о миграции, позволяющая посмотреть, чтобы было изменено в базе данных.
В разделе "Версии данных" можно посмотреть какие идентификаторы используются для сущностей на всех копиях проекта.
Ручные скрипты миграций
В связи с тем, что покрыть автоматическими миграциями абсолютно все сущности "1С-Битрикс" сложно, а в некоторых случаях невозможно, был добавлен механизм "ручных" миграций, которые создаются программистом в строго отведенном интерфейсе.
Для создания "ручной" миграции необходимо создать новый сценарий.
После создания сценария модуль укажет путь, по которому находится файл-заготовка "ручной" миграции. В классе, описывающим миграцию, для модификации предназначены два метода:
Начиная с нашего первого анонса модуля в прошлом году, мы начали его активно применять на наших проектах. Сначала это были небольшие проекты, потом их сложность росла и на данный момент модуль успешно применяется на проектах сложностью выше среднего.
Если у вас проект только начинает разрабатываться, то лучше всего использовать автоматические миграции, что позволит вам сохранить довольно много времени. Если же проект находится на поддержке и частое изменение структуры базы данных не планируется, тогда лучше использовать механизм “ручных” миграций, а автоматические отключить вовсе.
Расширение настроек модуля
Автоматические миграции на данный момент работают только с модулем "Информационные блоки". Теперь в настройках модуля можно указать какие виды сущностей модуля “Инфоблоки” попадают под синхронизацию.
К примеру, можно переносить между копиями проекта только инфоблоки, не учитывая их свойства и разделы. Переносить только свойства или разделы без инфоблоков нельзя.
Защита версии копии проекта
При переносе проекта с одной машины на другую получаются идентичные копии проектов с точки зрения модуля миграций и поэтому необходимо менять версию платформы у нового разработчика, что не всегда делалось и приводило к ошибкам в работе модуля. Для устранения человеческого фактора добавлена проверка на уникальность версии проекта в модуле миграций. При переходе в раздел "Версии платформ" система автоматически подсветит красным информацию о версии платформы.
Также, если не сменить версию проекта, то при попытке выполнить манипуляции с сущностями, которые находятся под автоматическими миграциями (как пример, добавление инфоблока), возникнет исключение в коде.
Кроме этого, была добавлена подпись для идентификации владельца копии проекта, что удобно при просмотре лога миграций и других отладочных действиях.
Расширенная информация о миграциях
Работа миграций на первых порах напоминала черный ящик без возможности узнать, что и когда менялось на проекте. Для удобства использования и "разбора полетов" был добавлен учет миграций и идентификаторов данных на всех копиях проекта.
В журнале изменений можно посмотреть список примененных миграций. В списке доступна информация о дате применения миграции, откуда она пришла, кто делал применение.
Также доступна более подробная информация о миграции, позволяющая посмотреть, чтобы было изменено в базе данных.
В разделе "Версии данных" можно посмотреть какие идентификаторы используются для сущностей на всех копиях проекта.
Ручные скрипты миграций
В связи с тем, что покрыть автоматическими миграциями абсолютно все сущности "1С-Битрикс" сложно, а в некоторых случаях невозможно, был добавлен механизм "ручных" миграций, которые создаются программистом в строго отведенном интерфейсе.
Для создания "ручной" миграции необходимо создать новый сценарий.
После создания сценария модуль укажет путь, по которому находится файл-заготовка "ручной" миграции. В классе, описывающим миграцию, для модификации предназначены два метода:
- commit() - содержит алгоритм применения миграции
- rollback() - содержит алгоритм отката миграции, если это возможно
Начиная с нашего первого анонса модуля в прошлом году, мы начали его активно применять на наших проектах. Сначала это были небольшие проекты, потом их сложность росла и на данный момент модуль успешно применяется на проектах сложностью выше среднего.
Если у вас проект только начинает разрабатываться, то лучше всего использовать автоматические миграции, что позволит вам сохранить довольно много времени. Если же проект находится на поддержке и частое изменение структуры базы данных не планируется, тогда лучше использовать механизм “ручных” миграций, а автоматические отключить вовсе.
Предлагаем еще прочесть
