1С-Битрикс и версионирование баз данных: выбираем инструмент

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

Абрахам Маслоу
В традиционной схеме веб-разработки программист имеет доступ к серверу и вносит изменения прямо на боевой сайт. Так поступать можно только если на сайте нет посетителей, в противном случае схема усложняется: рядом с prod-сайтом появляется dev-сайт для обкатывания всех новинок. Чем больше и сложнее сайт — тем больше должна быть команда разработчиков. И у каждого должна быть своя независимая копия сайта. Обычная разработка сменяется командной, появляются проблемы взаимодействия, в частности переноса наработок между серверами. Для кода есть универсальное решение -- системы контроля версий (VCS, Version Control System), например GIT, Mercurial.

А вот для проблемы автоматизированного слияния нескольких баз данных нет “серебряной пули”, для каждой CMS должен быть свой инструмент. Пока программисты работают каждый на своём dev-сайте, проблема незаметна как интроверт на празднике :) Но стоит заикнуться об объединении наработок на основном dev-сайте, она резко встаёт во весь рост, рвёт на себе тельняшку и начинает колотить других гостей.

В этой статье мы расскажем.

  • Как решали эту проблему раньше с помощью файлика “изменения БД.txt”.
  • Каким мы представляли себе идеальный модуль миграции БД.
  • Какие инструменты миграции для 1С-Битрикс мы нашли и чем они нас не устроили.
Самое вкусное мы выделили в отдельную статью :
  • Какой инструмент разработала ИНТЕРВОЛГА.
  • Как его получить, настроить, и начать делать миграции структуры данных быстро и без проблем.

Как обычно делают миграции

Для большинства проектов мы как и сотни других разработчиков 1С-Битрикс использовали файлик “изменения БД.txt”. В этот файл каждый программист эскизно записывал изменения, которые делал. Файл версионировался, так что после слияния веток и кода в нём оставался объединённый список изменений.

Всё хорошо, если забыть про 3 правила:

  1. Каждый программист должен записывать все изменения в файл максимально подробно.
  2. Тимлид должен дотошно повторять все изменения из файлика на новом сервере.
  3. Если возникает конфликт изменений — нужен консилиум разработчиков, чтобы решить, чьё изменение главнее.
Пример такого файла изменений:

  • Добавлен тип инфоблока "Push-уведомления" и инфоблок "Push-уведомления" (код:
  • push_notifications).
  • Добавлен инфоблок "Недоставленные уведомления" (код: delayed_notifications) в тип инфоблока "Push-уведомления".
  • Добавлено свойство "Время подтверждения уведомления" (код: TIME_RECEIVE) в инфоблок "Push-уведомления".
  • Удалено свойство "Картинки" (код: PICTURES) в инфоблоке "Новости".
  • В свойство "Тип" (код: TYPE) добавлен вариант списка ("IPv6") в инфоблоке "Конфигурация".
Чтобы сделать релиз и перенести изменения БД по этому сценарию, требуется в среднем несколько часов . И это мы еще не умножали на количество релизов в неделю и опустили промежуточную выкладку на dev-сайт для тестирования.

orig.58d3822e07d09_giphy_6.gif

Дыр в такой схеме больше чем в сыре Маасдам.

  • Требуется много времени крутого разработчика для переноса изменений.
  • Программист должен помнить про каждое сделанное им изменение в БД и правильно его описать в отчёте.
  • Если БД была изменена не программистом (агент, 1С, сторонние решения), то  вычислить их — очень нетривиальная задача.
Мы работали по такой схеме последние 3 года и всякое повидали. В 2017 году после стратегического совещания терпение лопнуло и отряд самоубийц из двух пряморуких программистов отправили на поиски/разработку волшебного инструмента объединения изменений БД. Так как в других CMS и CMF этот механизм называется "миграции", то и мы будем использовать этот термин.

Как на самом деле надо делать миграции

Требования к новому механизму озвучили руководители и техлиды:

  • Настройка . Должна быть возможность выбора, что именно будет мигрировать (В одном проекте нам нужны инфоблоки, в другом группы пользователей, а в третьем — всё сразу).
  • Авторство . Изменения БД должны фиксироваться в репозитории. Это отличное решение проблемы анонимных изменений в БД.
  • Автоматизация . Избавиться от ручной работы (запись изменений в ходе разработки, поиск внешних изменений в БД, воссоздание изменений на другом сервере при переносе).
  • Поддержка внешних изменений . Модуль не должен ломаться, если изменения будут внесены через 1С, вручную администратором при редактировании сайта, агентом или любым другим способом.
  • Версионирование . Должна быть возможность откатиться с любой версии БД на любую другую. При этом код сайта и структура БД должны соответствовать друг другу.
Оказалось, что в Marketplace уже были похожие по нашим требованиям решения.
  1. Миграции для разработчиков
  2. Копир: Миграция данных
  3. Миграции схемы данных

Мы провели небольшой тест-драйв этих модулей, чтобы понять, насколько они нам подходят.

Сравнение модулей миграции из MarketPlace

Пример

Задача приближена к реальности: имеется prod сайт с 4 инфоблоками 2 типов и две свежих песочницы для программистов.

В новостях есть свойство “Картинки новостей”.

Задачи для первого программиста:

  • Удалить свойство “Картинки новостей” из инфоблока новостей.
  • Перенести слайдер на страницу “О компании”, (т.е. изменить шаблоны url путей)
  • Удалить ИБ “Отзывы”
Задачи для второго программиста:
  • Добавить свойство “Редактор” инфоблоку новостей
  • Перевести слайдер на ЧПУ
Задача для техлида: объединить изменения с двух песочниц на prod-сайте для тестирования и демонстрации менеджеру проекта.

Миграции с помощью модуля «Миграции для разработчиков»

Модуль исповедует подход “в любой непонятной ситуации пиши инсталлятор”. Инсталлятор — это класс с двумя методами: up (накатить миграцию) и down (соответственно, откатить миграцию). Модуль берёт на себя установку/удаление файлов миграции и предоставляет интерфейс в панели управления сайтом. Инсталляторы хранятся в виде php-файлов по пути /local/php_interface/migrations/*.

Примечание: показана работа для программиста 1, т.к. для второго программиста она идентична.

Создадим файл миграции

Метод up для “Наката” и down для “Отката” миграции:

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

pasted image 0 (3).png

Готовый код инсталлятора отправляется в репозиторий.

Второй программист параллельно делает свои инсталляторы и тоже отправляет их в репозиторий.

Техлид на prod сайте делает pull. На странице модуля появились два новых файла миграции:

После нажатия “Установить новые” на prod-сайте произошли изменения.

  • Свойство “EDITOR” - создалось.
  • Свойство “PICS_NEWS” - удалилось
  • Сначала применилась миграция второго разработчика, изменив шаблон ссылок на ЧПУ
  • Потом шаблоны ссылок изменились на раздел “*/about/”.
Плюсы:
  • API для работы с инфоблоками, предоставленное модулем.
  • Интерфейс для применения или отката миграций.
  • Частичная автоматизация процесса (для переноса достаточно нажать кнопочку).
Минусы:
  • Полная автоматизация миграции не появилась, все действия всё равно необходимо записывать. Но уже не текстом, а в виде php-кода (который ещё и тестировать не помешает).
  • Не все поля, даже на сущностях инфоблоков, учтены.
  • Не отслеживаются конфликты (изменения разными программистами бд в одном месте).
  • Все изменения БД должны вноситься ТОЛЬКО программистом . Или же после изменений, сделанных кем-либо программист должен просматривать БД, и восстанавливать картину места преступления, программируя инсталлятор.
  • API модуля работает с данными по ID, который в разных БД может отличаться.

Миграции с помощью модуля «Копир: Миграция данных»

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

Для начала модуль надо установить и настроить подключения к другим базам данных.

Чтобы перенести измененную структуру инфоблоков необходимо перейти в “Сервисы”, там появился пункт Копир, с подпунктами для копирования разных сущностей:

Нашим экспериментаторам нужен пункт “Копирование инфоблоков”.

Первый программист:

Второй программист:

Результат работы, или что попало на бой:

  • + Добавилось созданное свойство-ссылка на инфоблок “Сотрудники”.
  • - Настройки инфоблока (шаблоны url) не попали на prod.
  • - Удаление свойства никак не отобразилось на prod.
Плюсы:
  • Модуль платный, а значит поддерживаемый.

Минусы:

  • Модуль платный, а значит платить придется за каждый проект.
  • Мигрировать данные можно только в пределах одного сервера.
  • Мигрируют не все настройки инфоблоков.
  • Ничего не происходит со свойствами, которые удалили.
  • Можно мигрировать только: “Инфоблоки”, “Почтовые события и шаблоны”, “Опросы”, “Вебформы”.
Миграции с помощью модуля «Миграции схемы данных»;

На странице модуля есть подробная инструкция для установки модуля и настройки среды для разработки (клонирование prod сайта для разработчиков).

Установили модуль, клонировали prod сайт разработчикам в отдельные dev сайты, сделали изменения в инфоблоках и файлы сами создались.

Файлы создаются в директории, которую Вы выбираете в настройках модуля при установке. Он представляет собой минимизированный json, название которого является текущем временем зашифрованным в md5.

Пример файла:

 

Чтобы перенести изменения, нужно перенести созданные файлы на prod сайт, и перейти в Настройки->Миграции данных (Обновление). Там будет показан список обновлений.

Чтобы применить обновления, достаточно нажать кнопку “Обновить”.

pasted image 0 (8).png

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

Плюсы:

  • Четкая автоматизация процесса.
  • Отдельный файлы изменений.
Минусы
  • Отслеживание только миграции инфоблоков.
  • Не отслеживаются конфликты изменений.

Результат сравнения модулей миграции

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

Требования / критерии Миграции для разработчиков Копир: Миграция данных Миграции схемы данных Модуль ИНТЕРВОЛГИ
Возможность выбора сущностей для миграции Да Да Нет Да
Авторство изменений Да Да Да Да
Автоматизация миграции данных Да* Да Да Да
Поддержка любых изменений Да Да Нет Да
Версионирование Да Нет Да Да
Модуль предупреждает о конфликтующих изменениях Нет Нет Нет Да
Набор сущностей для миграции Нет ограничений ИБ, Формы, Опросы, почтовые события ИБ ИБ, группы пользователей, почтовые события, пользовательские поля, HL, культура + языки + сайты, sale, catalog
На миграцию не влияет один ли это сервер или разные Да Нет Да Да

* Автоматизация заключается только в применении или откате изменений. Все изменения программист должен писать сам через API битрикса или модуля в файлах миграции.

Выводы

Главный минус рассмотренных модулей в том, что ни один из них не то, чтобы не решает проблему с конфликтами при релизе, они их даже не определяют. Также есть недостатки у каждого модуля по отдельности, такие как “нет полной автоматизации”, модуль платный, разработчики сделали акцент на ИБ и др.

Мы очень хотели найти готовое решение. С одной стороны, с нашими требованиями этого не получилось сделать. С другой - количество проектов на которых работает 2+ программистов постоянно росло и терпеть уже не было сил.

И мы сделали свой инструмент для миграций баз данных в 1С-Битрикс. При разработке модуля мы учли озвученные выше требования и попытались сделать идеальный инструмент для переноса изменений БД.


Что получилось - читайте в следующей статье .


Комментарии (2)

...
  • Андрей Рябин
  • 25.07.2017 20:51:02
Здравствуйте, спасибо за интересный обзор, было приятно почитать про свой модуль "Миграции для разработчиков":)

Единственное, я бы хотел отметить пункт "API модуля работает с данными по ID, который в разных БД может отличаться." - это не совсем так, ведь весь код пишут разработчики сами, значит могут привязываться например к символьными кодам. А в апи модуля есть методы получения id по коду, например:
$iblockId = $helper->Iblock()->getIblockId('news');

То есть пример который вы привели с const IBLOCK_NEWS = 1;
не совсем корректный, так писать действительно не надо.

Примеры кода миграций можно посмотреть тут: https://bitbucket.org/andrey_ryabin/sprint.migration/src/master/examples/?at=master

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

Что касается вашего модуля - это большой шаг вперед как мне кажется, похожая логика есть у symfony doctrine с ее схемой бд.
Жму вам руку за то что начали делать такую схему для битриксовых сущностей.
...
  • Дерманов Марк
  • 01.08.2017 17:59:23
Отличный обзор, давно была такая идея.
Отличный ход!)
Это одна из реально важных ниш в битриксе, которые до сих пор не были закрыты столь комплексным решением.