- Как обычно делают миграции
- Как на самом деле надо делать миграции
- Сравнение модулей миграции из MarketPlace
- Выводы
В традиционной схеме веб-разработки программист имеет доступ к серверу и вносит изменения прямо на боевой сайт. Так поступать можно только если на сайте нет посетителей, в противном случае схема усложняется: рядом с prod-сайтом появляется dev-сайт для обкатывания всех новинок. Чем больше и сложнее сайт — тем больше должна быть команда разработчиков. И у каждого должна быть своя независимая копия сайта. Обычная разработка сменяется командной, появляются проблемы взаимодействия, в частности переноса наработок между серверами. Для кода есть универсальное решение -- системы контроля версий (VCS, Version Control System), например GIT, Mercurial.Если ваш единственный инструмент — молоток,
то каждая проблема становится похожей на гвоздь.
А вот для проблемы автоматизированного слияния нескольких баз данных нет “серебряной пули”, для каждой CMS должен быть свой инструмент. Пока программисты работают каждый на своём dev-сайте, проблема незаметна как интроверт на празднике :) Но стоит заикнуться об объединении наработок на основном dev-сайте, она резко встаёт во весь рост, рвёт на себе тельняшку и начинает колотить других гостей.
В этой статье мы расскажем.
- Как решали эту проблему раньше с помощью файлика “изменения БД.txt”.
- Каким мы представляли себе идеальный модуль миграции БД.
- Какие инструменты миграции для 1С-Битрикс мы нашли и чем они нас не устроили.
- Какой инструмент разработала ИНТЕРВОЛГА.
- Как его получить, настроить, и начать делать миграции структуры данных быстро и без проблем.
Как обычно делают миграции
Для большинства проектов мы как и сотни других разработчиков 1С-Битрикс использовали файлик “изменения БД.txt”. В этот файл каждый программист эскизно записывал изменения, которые делал. Файл версионировался, так что после слияния веток и кода в нём оставался объединённый список изменений.
Всё хорошо, если забыть про 3 правила:
- Каждый программист должен записывать все изменения в файл максимально подробно.
- Тимлид должен дотошно повторять все изменения из файлика на новом сервере.
- Если возникает конфликт изменений — нужен консилиум разработчиков, чтобы решить, чьё изменение главнее.
- Добавлен тип инфоблока "Push-уведомления" и инфоблок "Push-уведомления" (код:
- push_notifications).
- Добавлен инфоблок "Недоставленные уведомления" (код: delayed_notifications) в тип инфоблока "Push-уведомления".
- Добавлено свойство "Время подтверждения уведомления" (код: TIME_RECEIVE) в инфоблок "Push-уведомления".
- Удалено свойство "Картинки" (код: PICTURES) в инфоблоке "Новости".
- В свойство "Тип" (код: TYPE) добавлен вариант списка ("IPv6") в инфоблоке "Конфигурация".
Дыр в такой схеме больше чем в сыре Маасдам.
- Требуется много времени крутого разработчика для переноса изменений.
- Программист должен помнить про каждое сделанное им изменение в БД и правильно его описать в отчёте.
- Если БД была изменена не программистом (агент, 1С, сторонние решения), то вычислить их — очень нетривиальная задача.
Как на самом деле надо делать миграции
Требования к новому механизму озвучили руководители и техлиды:
- Настройка. Должна быть возможность выбора, что именно будет мигрировать (В одном проекте нам нужны инфоблоки, в другом группы пользователей, а в третьем — всё сразу).
- Авторство. Изменения БД должны фиксироваться в репозитории. Это отличное решение проблемы анонимных изменений в БД.
- Автоматизация. Избавиться от ручной работы (запись изменений в ходе разработки, поиск внешних изменений в БД, воссоздание изменений на другом сервере при переносе).
- Поддержка внешних изменений. Модуль не должен ломаться, если изменения будут внесены через 1С, вручную администратором при редактировании сайта, агентом или любым другим способом.
- Версионирование. Должна быть возможность откатиться с любой версии БД на любую другую. При этом код сайта и структура БД должны соответствовать друг другу.
Мы провели небольшой тест-драйв этих модулей, чтобы понять, насколько они нам подходят.
Сравнение модулей миграции из MarketPlace
Пример
Задача приближена к реальности: имеется prod сайт с 4 инфоблоками 2 типов и две свежих песочницы для программистов.
В новостях есть свойство “Картинки новостей”.
Задачи для первого программиста:
- Удалить свойство “Картинки новостей” из инфоблока новостей.
- Перенести слайдер на страницу “О компании”, (т.е. изменить шаблоны url путей)
- Удалить ИБ “Отзывы”
- Добавить свойство “Редактор” инфоблоку новостей
- Перевести слайдер на ЧПУ
Миграции с помощью модуля «Миграции для разработчиков»
Модуль исповедует подход “в любой непонятной ситуации пиши инсталлятор”. Инсталлятор — это класс с двумя методами: up (накатить миграцию) и down (соответственно, откатить миграцию). Модуль берёт на себя установку/удаление файлов миграции и предоставляет интерфейс в панели управления сайтом. Инсталляторы хранятся в виде php-файлов по пути /local/php_interface/migrations/*.
Примечание: показана работа для программиста 1, т.к. для второго программиста она идентична.
Создадим файл миграции
Метод up для “Наката” и down для “Отката” миграции:
Теперь инсталлятор появился в панели управления и доступен для запуска:
Готовый код инсталлятора отправляется в репозиторий.
Второй программист параллельно делает свои инсталляторы и тоже отправляет их в репозиторий.
Техлид на prod сайте делает pull. На странице модуля появились два новых файла миграции:
После нажатия “Установить новые” на prod-сайте произошли изменения.
- Свойство “EDITOR” - создалось.
- Свойство “PICS_NEWS” - удалилось
- Сначала применилась миграция второго разработчика, изменив шаблон ссылок на ЧПУ
- Потом шаблоны ссылок изменились на раздел “*/about/”.
- API для работы с инфоблоками, предоставленное модулем.
- Интерфейс для применения или отката миграций.
- Частичная автоматизация процесса (для переноса достаточно нажать кнопочку).
- Полная автоматизация миграции не появилась, все действия всё равно необходимо записывать. Но уже не текстом, а в виде php-кода (который ещё и тестировать не помешает).
- Не все поля, даже на сущностях инфоблоков, учтены.
- Не отслеживаются конфликты (изменения разными программистами бд в одном месте).
- Все изменения БД должны вноситься ТОЛЬКО программистом. Или же после изменений, сделанных кем-либо программист должен просматривать БД, и восстанавливать картину места преступления, программируя инсталлятор.
- API модуля работает с данными по ID, который в разных БД может отличаться.
Миграции с помощью модуля «Копир: Миграция данных»
Программисты, разрабатывающие данный модуль, предлагают настраивать подключения к базам данных других сайтов и обмениваться между ними. Весь обмен происходит как черный ящик, но для этого, например для инфоблока, выбрать подключение к БД, его тип, сам инфоблок и выбрать разделы, элементы и свойства, которые будет переносить.
Для начала модуль надо установить и настроить подключения к другим базам данных.
Чтобы перенести измененную структуру инфоблоков необходимо перейти в “Сервисы”, там появился пункт Копир, с подпунктами для копирования разных сущностей:
Нашим экспериментаторам нужен пункт “Копирование инфоблоков”.
Первый программист:
Второй программист:
Результат работы, или что попало на бой:
- + Добавилось созданное свойство-ссылка на инфоблок “Сотрудники”.
- - Настройки инфоблока (шаблоны url) не попали на prod.
- - Удаление свойства никак не отобразилось на prod.
- Модуль платный, а значит поддерживаемый.
Минусы:
- Модуль платный, а значит платить придется за каждый проект.
- Мигрировать данные можно только в пределах одного сервера.
- Мигрируют не все настройки инфоблоков.
- Ничего не происходит со свойствами, которые удалили.
- Можно мигрировать только: “Инфоблоки”, “Почтовые события и шаблоны”, “Опросы”, “Вебформы”.
Миграции с помощью модуля «Миграции схемы данных»
На странице модуля есть подробная инструкция для установки модуля и настройки среды для разработки (клонирование prod сайта для разработчиков).
Установили модуль, клонировали prod сайт разработчикам в отдельные dev сайты, сделали изменения в инфоблоках и файлы сами создались.
Файлы создаются в директории, которую Вы выбираете в настройках модуля при установке. Он представляет собой минимизированный json, название которого является текущем временем зашифрованным в md5.
Пример файла:
Чтобы перенести изменения, нужно перенести созданные файлы на prod сайт, и перейти в Настройки->Миграции данных (Обновление). Там будет показан список обновлений.
Чтобы применить обновления, достаточно нажать кнопку “Обновить”.
Проблема возникла опять только с конфликтующими шаблонами ссылок инфоблока.
Плюсы:
- Четкая автоматизация процесса.
- Отдельный файлы изменений.
- Отслеживание только миграции инфоблоков.
- Не отслеживаются конфликты изменений.
Результат сравнения модулей миграции
В этой таблице у нас сразу спойлер — возможности нашего модуля, подробнее о котором вы прочитаете в следующей статье.
| Требования / критерии | Миграции для разработчиков | Копир: Миграция данных | Миграции схемы данных | Модуль ИНТЕРВОЛГИ |
| Возможность выбора сущностей для миграции | Да | Да | Нет | Да |
| Авторство изменений | Да | Да | Да | Да |
| Автоматизация миграции данных | Да* | Да | Да | Да |
| Поддержка любых изменений | Да | Да | Нет | Да |
| Версионирование | Да | Нет | Да | Да |
| Модуль предупреждает о конфликтующих изменениях | Нет | Нет | Нет | Да |
| Набор сущностей для миграции | Нет ограничений | ИБ, Формы, Опросы, почтовые события | ИБ | ИБ, группы пользователей, почтовые события, пользовательские поля, HL, культура + языки + сайты, sale, catalog |
| На миграцию не влияет один ли это сервер или разные | Да | Нет | Да | Да |
* Автоматизация заключается только в применении или откате изменений. Все изменения программист должен писать сам через API битрикса или модуля в файлах миграции.
Выводы
Главный минус рассмотренных модулей в том, что ни один из них не то, чтобы не решает проблему с конфликтами при релизе, они их даже не определяют. Также есть недостатки у каждого модуля по отдельности, такие как “нет полной автоматизации”, модуль платный, разработчики сделали акцент на ИБ и др.
Мы очень хотели найти готовое решение. С одной стороны, с нашими требованиями этого не получилось сделать. С другой - количество проектов на которых работает 2+ программистов постоянно росло и терпеть уже не было сил.
И мы сделали свой инструмент для миграций баз данных в 1С-Битрикс. При разработке модуля мы учли озвученные выше требования и попытались сделать идеальный инструмент для переноса изменений БД.
Что получилось - читайте в следующей статье.
Статьи по теме
