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

Абрахам Маслоу
В традиционной схеме веб-разработки программист имеет доступ к серверу и вносит изменения прямо на боевой сайт. Так поступать можно только если на сайте нет посетителей, в противном случае схема усложняется: рядом с 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С-Битрикс. При разработке модуля мы учли озвученные выше требования и попытались сделать идеальный инструмент для переноса изменений БД.


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


Оцените статью
24.07.2017
Понравилась статья?
Поделитесь ссылкой с друзьями и коллегами!

Статьи по теме

Как b2b-платформа передает в 1С данные по новым контрагентам В этой статье мы расскажем, что происходит после того, как клиент зарегистрировал в б2б-кабинете новое юридическое лицо и сделал заказ, а также покажем, как...
Автоматизация и оптимизация бизнес-процессов — лонгрид, чтобы не запутаться Статья будет полезна всем, кто хочет улучшить эффективность своего бизнеса или узнать больше о возможностях автоматизации бизнес-процессов для повышения ко...
10 обязательных задач поддержки сайта на БитриксСтатья посвящена организации поддержки сайтов на Битрикс. Здесь не только про решение технических проблем и устранение багов. Здесь про развитие живых проектов...
B2B-SaaS или B2B-система (платформа+CRM) на вашем сервере: плюс и минусы, что выбрать? Введение Эта статья для коммерческих директоров, руководителей отделов продаж производственных и оптово-торговых компаний, которые ищут инструменты для ро...
Обзор международных исследований о тенденциях развития B2B-сегмента Важность темы — рост B2B-продаж в онлайне В современном бизнесе наблюдается стремительный переход в online оптовых продаж. Это стало одной из ключевых тен...
Несколько способов сделать оптовый заказ на портале — Обновление B2B-платформы (v2.0) Коллеги, спешим поделиться важной новостью! Мы обновили один из наших флагманских продуктов — готовую платформу оптовых продаж. B2B-платформа v2.0 сочетает...
Мы работаем по одному из двух форматов:
  • аренда команды (от 2 человек, не менее 3 месяцев);
  • итерации с фиксированной ценой (1-3 месяца длительностью).
ИНТЕРВОЛГА предоставляет:
  • регулярные онлайн-планерки с заказчиком;
  • квалифицированных специалистов;
  • организованную команду (находятся в одном помещении, что упрощает решение рабочих вопросов);
  • полную прозрачность и регулярность отчетов о результатах.
Ключевые услуги:
  • нагруженный интернет-магазин;
  • личный кабинет;
  • оптовые продажи — B2B-платформа;
  • маркетплейс;
  • технический аудит сайта;
  • Битрикс24 — корпоративные HR-порталы;
  • Битрикс24 — построение CRM-системы;
  • Битрикс24 — личные кабинеты сотрудников;
  • Битрикс24 — аудит портала;
  • 1С — интеграция с другими системами;
  • 1С — доработка системы;
  • маркетинг — комплексное интернет-продвижение;
  • маркетинг — продвижение для B2B.
Хотите получать лучшие статьи от INTERVOLGA раз в месяц?
Подпишитесь на рассылку — спамить не будем