Міграції бази даних в 1С-Бітрікс: швидко, правильно, надійно

  1. Міграції бази даних в 1С-Бітрікс: швидко, правильно, надійно Якщо Ви розробляєте проекти на 1С-Бітрікс...
  2. команди модуля
  3. Перевірка XML ID (команда validate)
  4. Автоматичне виправлення помилок XML ID (команда autofix)
  5. Експорт в * .xml-файли (команда export)
  6. Імпорт з * .xml-файлів (команда import)
  7. Генерація демо-контенту (команда для розробників generate)
  8. Тестування модуля (команда для розробників unittest)
  9. Формат XML файлів
  10. Синтаксис XML-файлів міграції даних
  11. Як користуватися модулем
  12. Використання XML ID замість ID в коді
  13. Виконання прикладу з інших модулів
  14. замість висновків
  15. Міграції бази даних в 1С-Бітрікс: швидко, правильно, надійно
  16. конфігурація модуля
  17. команди модуля
  18. Перевірка XML ID (команда validate)
  19. Автоматичне виправлення помилок XML ID (команда autofix)
  20. Експорт в * .xml-файли (команда export)
  21. Імпорт з * .xml-файлів (команда import)
  22. Генерація демо-контенту (команда для розробників generate)
  23. Тестування модуля (команда для розробників unittest)
  24. Формат XML файлів
  25. Синтаксис XML-файлів міграції даних
  26. Як користуватися модулем
  27. Використання XML ID замість ID в коді
  28. Виконання прикладу з інших модулів
  29. замість висновків
  30. Міграції бази даних в 1С-Бітрікс: швидко, правильно, надійно
  31. конфігурація модуля
  32. команди модуля
  33. Перевірка XML ID (команда validate)
  34. Автоматичне виправлення помилок XML ID (команда autofix)
  35. Експорт в * .xml-файли (команда export)
  36. Імпорт з * .xml-файлів (команда import)
  37. Генерація демо-контенту (команда для розробників generate)
  38. Тестування модуля (команда для розробників unittest)
  39. Формат XML файлів
  40. Синтаксис XML-файлів міграції даних
  41. Як користуватися модулем
  42. Використання XML ID замість ID в коді
  43. Виконання прикладу з інших модулів
  44. замість висновків

Міграції бази даних в 1С-Бітрікс: швидко, правильно, надійно

Якщо Ви розробляєте проекти на 1С-Бітрікс із залученням двох і більше програмістів, то Вам сюди.

ИнтерВолга ділиться з користувачами Інтернет-розробників своїм крутим інструментом для АВТОМАТИЧНОЇ міграції БД в 1С-Бітрікс.

Як справжні спортсмени, ми зробили три підходи до снаряда. Перший раз пробували

. Другий раз - починали свою розробку на швидку руку. Ну а вийшло тільки на третій раз.

При використанні нашого модуля, час на виконання релізу і перенесення зміни БД, скорочується з декількох годин до 10-20 хвилин (при відсутності конфліктів).

Серед величезного розмаїття даних в 1С-Бітрікс: Управління Сайтом для першого разу ми вибрали наступні сутності.

Для зіставлення записів між декількома БД потрібно вибрати унікальний ID. Рідні числові ID не підходять на цю роль - ними не можна керувати і вони можуть відрізнятися в різних БД.

Аналогічна проблема є при обміні товарами і замовленнями між сайтом і 1С. Там вона вирішується за допомогою унікального зовнішнього коду - XML_ID. Ось тільки не у всіх даних в БУС передбачено це поле. А у тих, що є, воно не завжди унікальне. Довелося нам зробити "надбудову" над системним полем XML ID. У таблиці нижче описані всі сутності з їх XML ID міграції.

Сутність XML ID міграції Група користувачів STRING_ID Тип поштового події LID + EVENT_NAME Поштовий шаблон md5 (EMAIL_FROM + EMAIL_TO + EVENT_NAME + сайти) Мова LID Культура NAME Сайт LID Налаштування шаблону сайту SITE_ID + TEMPLATE + md5 (CONDITION) UF-поле md5 (ENTITY_ID + FIELD_NAME ) Варіант списку UF-поля XML_ID highload-блок TABLE_NAME Поле highload-блоку md5 (highload-блок + FIELD_NAME) Варіант списку поля highload-блоку XML_ID Тип ціни XML_ID Тип платника md5 (NAME + сайти) Група властивостей замовлення md5 (NAME + Тип платника ) Властивість замовлення md5 (CODE + Тип платника) Варіант властивості замовлення md5 (VALUE + Властивість замовлення) Тип Інфоблоки ID Інфоблок XML_ID Властивість Інфоблоки Інфо блок + XML_ID Варіант властивості Інфоблоки Інфоблок + XML_ID Право на інфоблок md5 (Інфоблок + Група) Форма редагування Інфоблок + кілька полів форми Поле розділу Інфоблоки md5 (Інфоблок + FIELD_NAME) Варіант списку поля розділу Інфоблоки XML_ID

конфігурація модуля

Конфігурацію можна змінити у файлі /local/migrato/config.xml. До речі, папку / local / migrato / потрібно обов'язково додати в репозиторій - крім конфігурації тут же будуть і XML-файли експорту. Файл редагується тільки вручну через FTP / SSH / файловий менеджер БУС. Синтаксис файлу представлений в таблиці:

Вузол Батьківський вузол Опис <config> - Кореневий <module> <config> Налаштування міграції модуля <name> <module> Назва модуля <entity> <module> Сутність для міграції <name> <entity> Назва суті <options> <config> Мігріруемие настройки <exclude> <options> Регулярний вираз для виключення налаштувань з міграцій

Вузол Батьківський вузол Опис <config> - Кореневий <module> <config> Налаштування міграції модуля <name> <module> Назва модуля <entity> <module> Сутність для міграції <name> <entity> Назва суті <options> <config> Мігріруемие настройки <exclude> <options> Регулярний вираз для виключення налаштувань з міграцій

команди модуля

Для усунення проблем з таймаут сервера (і щоб надати теплу лампову атмосферу) вся робота з модулем після установки винесена в командний рядок. Точка входу: <папка модуля> /intervolga.migrato/tools/run.php (в прикладах для стислості буде позначена як run.php).

Інтерфейс модуля в командному рядку

Синтаксис простий:
$ Php run.php команда [опції]

Доступні команди:

  1. validate (перевірка XML ID)
  2. autofix (автоматичне виправлення помилок XML ID)
  3. export (експорт даних з БД в XML)
  4. import (імпорт даних з XML в БД)
  5. log (висновок логів останньої запущеної команди)

Сервісні команди (для розробників нових сутностей):

  1. generate (генерація демо-контенту)
  2. unittest (тестування модуля)

Доступні опції:

  1. -W або --win (змінити кодування на win-1251)
  2. -U або --utf (змінити кодування на UTF-8)
  3. -F або --fails (розширений висновок помилок після виконання команди)
  4. -v (короткий звіт по роботі команди)
  5. -vv (детальний звіт по роботі команди)

Перевірка XML ID (команда validate)

Модуль читає config.xml і перевіряє, щоб у всіх примірників сутностей були задані коректні XML ID. Команда нічого не змінює в БД. Критерії коректного XML ID:

  1. Не порожній.
  2. Чи не цілком числовий.
  3. Потрапляє під регулярний вираз /^[a-z0-9\-_#.]+$/i (допустимі літери латинського алфавіту, цифри, тире, підкреслення, решітка, точка).
  4. XML ID не повинен повторюватися в межах суті.

XML ID не повинен повторюватися в межах суті

Автоматичне виправлення помилок XML ID (команда autofix)

Виправлення помилок XML ID - відповідальний крок, тому і винесено в окрему команду. Увага: процес може привести до модифікації БД. Для всіх знайдених помилок XML ID викликається генератор XML_ID, що створює унікальний код суті.

Експорт в * .xml-файли (команда export)

  1. Модуль записує поточні настройки всіх перерахованих модулів в файли. Файли складаються в / local / migrato / <назва модуля> /option.xml.
  2. Модуль перевіряє XML ID. Робота триває тільки якщо немає помилок.
  3. Для кожного запису з перерахованих сутностей модуль створює файл: / local / migrato / <назва модуля> / <назва суті> / data- <xml id> .xml
  4. Якщо дані були видалені - у відповідному файлі проставляється атрибут deleted = true в вузлі <data>

xml   Якщо дані були видалені - у відповідному файлі проставляється атрибут deleted = true в вузлі <data>

Імпорт з * .xml-файлів (команда import)

  1. Модуль виконує розбір і імпорт налаштувань в БД.
  2. Модуль проводить перевірку даних. Робота триває тільки якщо немає помилок.
  3. Модуль читає data-файли і імпортує записи.
  4. Модуль перевіряє, чи залишилися суті з невирішеними залежностями. Якщо вони є - це помилка.
  5. Модуль видаляє файли, помічені атрибутом deleted = true.
  6. Модуль проставляє посилання в даних.
  7. Оновлення пошукового індексу, urlrewrite, скидання кешу // Адже ви не забуваєте робити все це при релізах :)?

Висновок логів попередньої команди (команда log)

Якщо при виконанні однієї з попередніх команд сталася помилка, побачити їх можна командою log. Використавши опцію --fails можна відфільтрувати всі записи, залишивши тільки повідомлення про помилки. Якщо ж вам зручніше працювати з БД, то всі помилки зберігаються в таблиці intervolga_migrato_log.

Генерація демо-контенту (команда для розробників generate)

Пам'ятайте, трава раніше була зеленішою, морозиво смачніше а модуль DEFA Tools був безкоштовним? Його генератор демо-контенту ми відтворювати, звичайно, не стали, але додати по 2 записи в кожну суті команда generate може. Команда корисна для розробників нових сутностей.

Тестування модуля (команда для розробників unittest)

Друга команда, корисна для розробників (і тестувальників). Виповнюється сценарій.

  1. export
  2. Файли XML копіюються в / local / migrato_old /
  3. import
  4. export
  5. diff папок / local / migrato / і / local / migrato_old /

Якщо все суті працюють правильно, diff буде порожнім. Якщо ж немає - це означає, що в коді суті є помилка і вона імпортується в базу неправильно.

Формат XML файлів

Синтаксис XML-файлів міграції налаштувань модулів

Синтаксис XML-файлів міграції налаштувань модулів

Вузол Батьківський вузол Опис <options> - Батьківський вузол <option> <options> Налаштування <name> <option> Назва настройки <value> <option> Значення настройки <site> <option> Сайт, для якого задано значення

Синтаксис XML-файлів міграції даних

Синтаксис XML-файлів міграції даних

Вузол Батьківський вузол Опис <data> - Батьківський вузол. Атрибут deleted каже, що дані були видалені <xml_id> <data> XML ID даних <dependency> <data> Вузол залежності <reference> <data> Вузол посилання <field> <data> Вузол простого поля <name> <dependency>
<Reference>
<Field> Назва поля <value> <dependency>
<Reference>
<Field> Значення поля

Як користуватися модулем

Щоб почати використовувати модуль необхідно на бойовому сайті створити оригінальний зліпок БД:

  1. Встановити модуль intervolga.migrato
  2. налаштувати /local/migrato/config.xml
  3. validate
    1. autofix при необхідності або ручне виправлення XML ID в БД
  4. export
  5. Додати папку / local / migrato / в git (він же у вас вже є)
  6. git commit & git push
  7. Зняти бекап з prod і розгорнути на dev1, dev2 ...

Щоб підготувати міграцію на пісочниці devX після закінчення роботи над завданням:

  1. validate
    1. autofix при необхідності або ручне виправлення XML ID в БД
  2. export
  3. git commit & git push

Виконати міграцію (реліз) на бойовому сайті:

  1. validate
    1. autofix при необхідності
  2. export (раптом на бою були невраховані в git'е зміни?)
    1. git commit при необхідності
  3. git pull
    1. вирішення конфліктів, якщо виникли
    2. git push, якщо виникли конфлікти
  4. import

Використання XML ID замість ID в коді

Допитливий читач-програміст може задати питання: як же тепер писати код, якщо використовувати ID - погано, а XML ID міграції не завжди збігається з XML ID суті?

Модуль надає API для отримання ID по XML ID:
\ Intervolga \ Migrato \ Data \ BaseData :: getPublicId ($ xmlId)

Метод використовує кешування, так що про продуктивність не варто турбуватися.

Якщо ви використовуєте константи для звернення до сутностей по ID, то вам тільки і потрібно - зробити наступну заміну.

було
було

стало
стало

А ось друга зміна прийняти буде не так просто. Візуальний редактор буса при роботі з компонентами генерує код, в якому явно фігурують "магічні" неунікальні числові ID.

Ось за таке хочеться Бітрікс від душі посварити. Генерація коду зашита дуже глибоко і кастомизировать її немає ніякої можливості. Ми не стали вигадувати хитрих способів підміни такого коду і просто ввели правило - візуальним редактором для редагування компонентів не користуємося. Програміст один раз налаштовує компонент, потім замінює ID на XML ID міграції і ніяких няш-мяш. Якщо знаєте спосіб краще - розкажіть в коментарях, з радістю приймемо на озброєння.

Виконання прикладу з інших модулів

І, наостанок, виконання загального прикладу нашим модулем. Відразу після установки перевірили всі записи на наявність зовнішніх ключів і виправили помилки:

Тепер можна створювати dev сайти для розробників - клонуємо prod і обов'язково робимо перший знімок бази даних (виконуємо команду експорт).

Після того, як кожен програміст виконає своє завдання на своєму сайті, він робить експорт. Так як зміни були зроблені тільки в ІБ модулі, то і експортувати інші модулі немає сенсу (Налаштування config файлу).

Після програміст робить Комміт експортованих файлів, і перед тим як виштовхнути файли на віддалений репозиторій необхідно перевірити, може інший програміст виконав завдання швидше (git pull).
На цьому кроці, не виключено виникнення конфлікту. Що ж, тут є 2 шляхи, дивлячись як Вам зручніше працювати. Якщо у вас git на серверах розробки, при конфлікті з'явиться таке попередження:

Відкриваєте файл, наприклад за допомогою vim (vi local / migato / iblock / type / ...) і вибираєте, хто з програмістів не бреше.

Після цього індексуєте файли і комитету.

Є ще другий шлях, якщо у вас гіт тільки на локальній машині, і синхронізуєте всі файли за допомогою Гіта, але на локальній машині. На прикладі показано виникнення конфлікту в IDE PHPStorm.

На прикладі показано виникнення конфлікту в IDE PHPStorm

Як тільки всі конфлікти дозволені, програміст повинен виштовхнути зміни на сервер.

Після того, як всі програмісти виштовхнули свої зміни, версія бази даних в системі управління версій стабілізується. Це означає, що настав час робити реліз. Після якого, щоб оновити будь-який сайт (будь то сайт для розробки або prod), досить трьох глобальний речей:

  • виконати pull
  • Перевірити config файл (які саме модулі та сутності нам потрібні)
  • Виконати імпорт даних

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

замість висновків

Інструмент для міграції змін БД життєво необхідний при відповідальної командній роботі над проектами. До сьогоднішнього дня ця задача в світі 1С-Бітрікс вирішувалася дуже погано.

Ми ж розробили промислове рішення цього завдання і віддаємо його безкоштовно всім бажаючим. Користуйтеся, пропонуйте поліпшення, беріть участь в розвитку, ми будемо раді. Щоб отримати посилання на установку модуля міграцій для Бітрікс, "поділіться" статтею в соцмережах і вкажіть посилання в форму під статтею. Посилання на репозиторій з документацією прийде вам на пошту.

Міграції бази даних в 1С-Бітрікс: швидко, правильно, надійно

Якщо Ви розробляєте проекти на 1С-Бітрікс із залученням двох і більше програмістів, то Вам сюди.

ИнтерВолга ділиться з користувачами Інтернет-розробників своїм крутим інструментом для АВТОМАТИЧНОЇ міграції БД в 1С-Бітрікс.

Як справжні спортсмени, ми зробили три підходи до снаряда. Перший раз пробували

. Другий раз - починали свою розробку на швидку руку. Ну а вийшло тільки на третій раз.

При використанні нашого модуля, час на виконання релізу і перенесення зміни БД, скорочується з декількох годин до 10-20 хвилин (при відсутності конфліктів).

Серед величезного розмаїття даних в 1С-Бітрікс: Управління Сайтом для першого разу ми вибрали наступні сутності.

Для зіставлення записів між декількома БД потрібно вибрати унікальний ID. Рідні числові ID не підходять на цю роль - ними не можна керувати і вони можуть відрізнятися в різних БД.

Аналогічна проблема є при обміні товарами і замовленнями між сайтом і 1С. Там вона вирішується за допомогою унікального зовнішнього коду - XML_ID. Ось тільки не у всіх даних в БУС передбачено це поле. А у тих, що є, воно не завжди унікальне. Довелося нам зробити "надбудову" над системним полем XML ID. У таблиці нижче описані всі сутності з їх XML ID міграції.

Сутність XML ID міграції Група користувачів STRING_ID Тип поштового події LID + EVENT_NAME Поштовий шаблон md5 (EMAIL_FROM + EMAIL_TO + EVENT_NAME + сайти) Мова LID Культура NAME Сайт LID Налаштування шаблону сайту SITE_ID + TEMPLATE + md5 (CONDITION) UF-поле md5 (ENTITY_ID + FIELD_NAME ) Варіант списку UF-поля XML_ID highload-блок TABLE_NAME Поле highload-блоку md5 (highload-блок + FIELD_NAME) Варіант списку поля highload-блоку XML_ID Тип ціни XML_ID Тип платника md5 (NAME + сайти) Група властивостей замовлення md5 (NAME + Тип платника ) Властивість замовлення md5 (CODE + Тип платника) Варіант властивості замовлення md5 (VALUE + Властивість замовлення) Тип Інфоблоки ID Інфоблок XML_ID Властивість Інфоблоки Інфо блок + XML_ID Варіант властивості Інфоблоки Інфоблок + XML_ID Право на інфоблок md5 (Інфоблок + Група) Форма редагування Інфоблок + кілька полів форми Поле розділу Інфоблоки md5 (Інфоблок + FIELD_NAME) Варіант списку поля розділу Інфоблоки XML_ID

конфігурація модуля

Конфігурацію можна змінити у файлі /local/migrato/config.xml. До речі, папку / local / migrato / потрібно обов'язково додати в репозиторій - крім конфігурації тут же будуть і XML-файли експорту. Файл редагується тільки вручну через FTP / SSH / файловий менеджер БУС. Синтаксис файлу представлений в таблиці:

Вузол Батьківський вузол Опис <config> - Кореневий <module> <config> Налаштування міграції модуля <name> <module> Назва модуля <entity> <module> Сутність для міграції <name> <entity> Назва суті <options> <config> Мігріруемие настройки <exclude> <options> Регулярний вираз для виключення налаштувань з міграцій

Вузол Батьківський вузол Опис <config> - Кореневий <module> <config> Налаштування міграції модуля <name> <module> Назва модуля <entity> <module> Сутність для міграції <name> <entity> Назва суті <options> <config> Мігріруемие настройки <exclude> <options> Регулярний вираз для виключення налаштувань з міграцій

команди модуля

Для усунення проблем з таймаут сервера (і щоб надати теплу лампову атмосферу) вся робота з модулем після установки винесена в командний рядок. Точка входу: <папка модуля> /intervolga.migrato/tools/run.php (в прикладах для стислості буде позначена як run.php).

Інтерфейс модуля в командному рядку

Синтаксис простий:
$ Php run.php команда [опції]

Доступні команди:

  1. validate (перевірка XML ID)
  2. autofix (автоматичне виправлення помилок XML ID)
  3. export (експорт даних з БД в XML)
  4. import (імпорт даних з XML в БД)
  5. log (висновок логів останньої запущеної команди)

Сервісні команди (для розробників нових сутностей):

  1. generate (генерація демо-контенту)
  2. unittest (тестування модуля)

Доступні опції:

  1. -W або --win (змінити кодування на win-1251)
  2. -U або --utf (змінити кодування на UTF-8)
  3. -F або --fails (розширений висновок помилок після виконання команди)
  4. -v (короткий звіт по роботі команди)
  5. -vv (детальний звіт по роботі команди)

Перевірка XML ID (команда validate)

Модуль читає config.xml і перевіряє, щоб у всіх примірників сутностей були задані коректні XML ID. Команда нічого не змінює в БД. Критерії коректного XML ID:

  1. Не порожній.
  2. Чи не цілком числовий.
  3. Потрапляє під регулярний вираз /^[a-z0-9\-_#.]+$/i (допустимі літери латинського алфавіту, цифри, тире, підкреслення, решітка, точка).
  4. XML ID не повинен повторюватися в межах суті.

XML ID не повинен повторюватися в межах суті

Автоматичне виправлення помилок XML ID (команда autofix)

Виправлення помилок XML ID - відповідальний крок, тому і винесено в окрему команду. Увага: процес може привести до модифікації БД. Для всіх знайдених помилок XML ID викликається генератор XML_ID, що створює унікальний код суті.

Експорт в * .xml-файли (команда export)

  1. Модуль записує поточні настройки всіх перерахованих модулів в файли. Файли складаються в / local / migrato / <назва модуля> /option.xml.
  2. Модуль перевіряє XML ID. Робота триває тільки якщо немає помилок.
  3. Для кожного запису з перерахованих сутностей модуль створює файл: / local / migrato / <назва модуля> / <назва суті> / data- <xml id> .xml
  4. Якщо дані були видалені - у відповідному файлі проставляється атрибут deleted = true в вузлі <data>

xml   Якщо дані були видалені - у відповідному файлі проставляється атрибут deleted = true в вузлі <data>

Імпорт з * .xml-файлів (команда import)

  1. Модуль виконує розбір і імпорт налаштувань в БД.
  2. Модуль проводить перевірку даних. Робота триває тільки якщо немає помилок.
  3. Модуль читає data-файли і імпортує записи.
  4. Модуль перевіряє, чи залишилися суті з невирішеними залежностями. Якщо вони є - це помилка.
  5. Модуль видаляє файли, помічені атрибутом deleted = true.
  6. Модуль проставляє посилання в даних.
  7. Оновлення пошукового індексу, urlrewrite, скидання кешу // Адже ви не забуваєте робити все це при релізах :)?

Висновок логів попередньої команди (команда log)

Якщо при виконанні однієї з попередніх команд сталася помилка, побачити їх можна командою log. Використавши опцію --fails можна відфільтрувати всі записи, залишивши тільки повідомлення про помилки. Якщо ж вам зручніше працювати з БД, то всі помилки зберігаються в таблиці intervolga_migrato_log.

Генерація демо-контенту (команда для розробників generate)

Пам'ятайте, трава раніше була зеленішою, морозиво смачніше а модуль DEFA Tools був безкоштовним? Його генератор демо-контенту ми відтворювати, звичайно, не стали, але додати по 2 записи в кожну суті команда generate може. Команда корисна для розробників нових сутностей.

Тестування модуля (команда для розробників unittest)

Друга команда, корисна для розробників (і тестувальників). Виповнюється сценарій.

  1. export
  2. Файли XML копіюються в / local / migrato_old /
  3. import
  4. export
  5. diff папок / local / migrato / і / local / migrato_old /

Якщо все суті працюють правильно, diff буде порожнім. Якщо ж немає - це означає, що в коді суті є помилка і вона імпортується в базу неправильно.

Формат XML файлів

Синтаксис XML-файлів міграції налаштувань модулів

Синтаксис XML-файлів міграції налаштувань модулів

Вузол Батьківський вузол Опис <options> - Батьківський вузол <option> <options> Налаштування <name> <option> Назва настройки <value> <option> Значення настройки <site> <option> Сайт, для якого задано значення

Синтаксис XML-файлів міграції даних

Синтаксис XML-файлів міграції даних

Вузол Батьківський вузол Опис <data> - Батьківський вузол. Атрибут deleted каже, що дані були видалені <xml_id> <data> XML ID даних <dependency> <data> Вузол залежності <reference> <data> Вузол посилання <field> <data> Вузол простого поля <name> <dependency>
<Reference>
<Field> Назва поля <value> <dependency>
<Reference>
<Field> Значення поля

Як користуватися модулем

Щоб почати використовувати модуль необхідно на бойовому сайті створити оригінальний зліпок БД:

  1. Встановити модуль intervolga.migrato
  2. налаштувати /local/migrato/config.xml
  3. validate
    1. autofix при необхідності або ручне виправлення XML ID в БД
  4. export
  5. Додати папку / local / migrato / в git (він же у вас вже є)
  6. git commit & git push
  7. Зняти бекап з prod і розгорнути на dev1, dev2 ...

Щоб підготувати міграцію на пісочниці devX після закінчення роботи над завданням:

  1. validate
    1. autofix при необхідності або ручне виправлення XML ID в БД
  2. export
  3. git commit & git push

Виконати міграцію (реліз) на бойовому сайті:

  1. validate
    1. autofix при необхідності
  2. export (раптом на бою були невраховані в git'е зміни?)
    1. git commit при необхідності
  3. git pull
    1. вирішення конфліктів, якщо виникли
    2. git push, якщо виникли конфлікти
  4. import

Використання XML ID замість ID в коді

Допитливий читач-програміст може задати питання: як же тепер писати код, якщо використовувати ID - погано, а XML ID міграції не завжди збігається з XML ID суті?

Модуль надає API для отримання ID по XML ID:
\ Intervolga \ Migrato \ Data \ BaseData :: getPublicId ($ xmlId)

Метод використовує кешування, так що про продуктивність не варто турбуватися.

Якщо ви використовуєте константи для звернення до сутностей по ID, то вам тільки і потрібно - зробити наступну заміну.

було
було

стало
стало

А ось друга зміна прийняти буде не так просто. Візуальний редактор буса при роботі з компонентами генерує код, в якому явно фігурують "магічні" неунікальні числові ID.

Ось за таке хочеться Бітрікс від душі посварити. Генерація коду зашита дуже глибоко і кастомизировать її немає ніякої можливості. Ми не стали вигадувати хитрих способів підміни такого коду і просто ввели правило - візуальним редактором для редагування компонентів не користуємося. Програміст один раз налаштовує компонент, потім замінює ID на XML ID міграції і ніяких няш-мяш. Якщо знаєте спосіб краще - розкажіть в коментарях, з радістю приймемо на озброєння.

Виконання прикладу з інших модулів

І, наостанок, виконання загального прикладу нашим модулем. Відразу після установки перевірили всі записи на наявність зовнішніх ключів і виправили помилки:

Тепер можна створювати dev сайти для розробників - клонуємо prod і обов'язково робимо перший знімок бази даних (виконуємо команду експорт).

Після того, як кожен програміст виконає своє завдання на своєму сайті, він робить експорт. Так як зміни були зроблені тільки в ІБ модулі, то і експортувати інші модулі немає сенсу (Налаштування config файлу).

Після програміст робить Комміт експортованих файлів, і перед тим як виштовхнути файли на віддалений репозиторій необхідно перевірити, може інший програміст виконав завдання швидше (git pull).
На цьому кроці, не виключено виникнення конфлікту. Що ж, тут є 2 шляхи, дивлячись як Вам зручніше працювати. Якщо у вас git на серверах розробки, при конфлікті з'явиться таке попередження:

Відкриваєте файл, наприклад за допомогою vim (vi local / migato / iblock / type / ...) і вибираєте, хто з програмістів не бреше.

Після цього індексуєте файли і комитету.

Є ще другий шлях, якщо у вас гіт тільки на локальній машині, і синхронізуєте всі файли за допомогою Гіта, але на локальній машині. На прикладі показано виникнення конфлікту в IDE PHPStorm.

На прикладі показано виникнення конфлікту в IDE PHPStorm

Як тільки всі конфлікти дозволені, програміст повинен виштовхнути зміни на сервер.

Після того, як всі програмісти виштовхнули свої зміни, версія бази даних в системі управління версій стабілізується. Це означає, що настав час робити реліз. Після якого, щоб оновити будь-який сайт (будь то сайт для розробки або prod), досить трьох глобальний речей:

  • виконати pull
  • Перевірити config файл (які саме модулі та сутності нам потрібні)
  • Виконати імпорт даних

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

замість висновків

Інструмент для міграції змін БД життєво необхідний при відповідальної командній роботі над проектами. До сьогоднішнього дня ця задача в світі 1С-Бітрікс вирішувалася дуже погано.

Ми ж розробили промислове рішення цього завдання і віддаємо його безкоштовно всім бажаючим. Користуйтеся, пропонуйте поліпшення, беріть участь в розвитку, ми будемо раді. Щоб отримати посилання на установку модуля міграцій для Бітрікс, "поділіться" статтею в соцмережах і вкажіть посилання в форму під статтею. Посилання на репозиторій з документацією прийде вам на пошту.

Міграції бази даних в 1С-Бітрікс: швидко, правильно, надійно

Якщо Ви розробляєте проекти на 1С-Бітрікс із залученням двох і більше програмістів, то Вам сюди.

ИнтерВолга ділиться з користувачами Інтернет-розробників своїм крутим інструментом для АВТОМАТИЧНОЇ міграції БД в 1С-Бітрікс.

Як справжні спортсмени, ми зробили три підходи до снаряда. Перший раз пробували

. Другий раз - починали свою розробку на швидку руку. Ну а вийшло тільки на третій раз.

При використанні нашого модуля, час на виконання релізу і перенесення зміни БД, скорочується з декількох годин до 10-20 хвилин (при відсутності конфліктів).

Серед величезного розмаїття даних в 1С-Бітрікс: Управління Сайтом для першого разу ми вибрали наступні сутності.

Для зіставлення записів між декількома БД потрібно вибрати унікальний ID. Рідні числові ID не підходять на цю роль - ними не можна керувати і вони можуть відрізнятися в різних БД.

Аналогічна проблема є при обміні товарами і замовленнями між сайтом і 1С. Там вона вирішується за допомогою унікального зовнішнього коду - XML_ID. Ось тільки не у всіх даних в БУС передбачено це поле. А у тих, що є, воно не завжди унікальне. Довелося нам зробити "надбудову" над системним полем XML ID. У таблиці нижче описані всі сутності з їх XML ID міграції.

Сутність XML ID міграції Група користувачів STRING_ID Тип поштового події LID + EVENT_NAME Поштовий шаблон md5 (EMAIL_FROM + EMAIL_TO + EVENT_NAME + сайти) Мова LID Культура NAME Сайт LID Налаштування шаблону сайту SITE_ID + TEMPLATE + md5 (CONDITION) UF-поле md5 (ENTITY_ID + FIELD_NAME ) Варіант списку UF-поля XML_ID highload-блок TABLE_NAME Поле highload-блоку md5 (highload-блок + FIELD_NAME) Варіант списку поля highload-блоку XML_ID Тип ціни XML_ID Тип платника md5 (NAME + сайти) Група властивостей замовлення md5 (NAME + Тип платника ) Властивість замовлення md5 (CODE + Тип платника) Варіант властивості замовлення md5 (VALUE + Властивість замовлення) Тип Інфоблоки ID Інфоблок XML_ID Властивість Інфоблоки Інфо блок + XML_ID Варіант властивості Інфоблоки Інфоблок + XML_ID Право на інфоблок md5 (Інфоблок + Група) Форма редагування Інфоблок + кілька полів форми Поле розділу Інфоблоки md5 (Інфоблок + FIELD_NAME) Варіант списку поля розділу Інфоблоки XML_ID

конфігурація модуля

Конфігурацію можна змінити у файлі /local/migrato/config.xml. До речі, папку / local / migrato / потрібно обов'язково додати в репозиторій - крім конфігурації тут же будуть і XML-файли експорту. Файл редагується тільки вручну через FTP / SSH / файловий менеджер БУС. Синтаксис файлу представлений в таблиці:

Вузол Батьківський вузол Опис <config> - Кореневий <module> <config> Налаштування міграції модуля <name> <module> Назва модуля <entity> <module> Сутність для міграції <name> <entity> Назва суті <options> <config> Мігріруемие настройки <exclude> <options> Регулярний вираз для виключення налаштувань з міграцій

Вузол Батьківський вузол Опис <config> - Кореневий <module> <config> Налаштування міграції модуля <name> <module> Назва модуля <entity> <module> Сутність для міграції <name> <entity> Назва суті <options> <config> Мігріруемие настройки <exclude> <options> Регулярний вираз для виключення налаштувань з міграцій

команди модуля

Для усунення проблем з таймаут сервера (і щоб надати теплу лампову атмосферу) вся робота з модулем після установки винесена в командний рядок. Точка входу: <папка модуля> /intervolga.migrato/tools/run.php (в прикладах для стислості буде позначена як run.php).

Інтерфейс модуля в командному рядку

Синтаксис простий:
$ Php run.php команда [опції]

Доступні команди:

  1. validate (перевірка XML ID)
  2. autofix (автоматичне виправлення помилок XML ID)
  3. export (експорт даних з БД в XML)
  4. import (імпорт даних з XML в БД)
  5. log (висновок логів останньої запущеної команди)

Сервісні команди (для розробників нових сутностей):

  1. generate (генерація демо-контенту)
  2. unittest (тестування модуля)

Доступні опції:

  1. -W або --win (змінити кодування на win-1251)
  2. -U або --utf (змінити кодування на UTF-8)
  3. -F або --fails (розширений висновок помилок після виконання команди)
  4. -v (короткий звіт по роботі команди)
  5. -vv (детальний звіт по роботі команди)

Перевірка XML ID (команда validate)

Модуль читає config.xml і перевіряє, щоб у всіх примірників сутностей були задані коректні XML ID. Команда нічого не змінює в БД. Критерії коректного XML ID:

  1. Не порожній.
  2. Чи не цілком числовий.
  3. Потрапляє під регулярний вираз /^[a-z0-9\-_#.]+$/i (допустимі літери латинського алфавіту, цифри, тире, підкреслення, решітка, точка).
  4. XML ID не повинен повторюватися в межах суті.

XML ID не повинен повторюватися в межах суті

Автоматичне виправлення помилок XML ID (команда autofix)

Виправлення помилок XML ID - відповідальний крок, тому і винесено в окрему команду. Увага: процес може привести до модифікації БД. Для всіх знайдених помилок XML ID викликається генератор XML_ID, що створює унікальний код суті.

Експорт в * .xml-файли (команда export)

  1. Модуль записує поточні настройки всіх перерахованих модулів в файли. Файли складаються в / local / migrato / <назва модуля> /option.xml.
  2. Модуль перевіряє XML ID. Робота триває тільки якщо немає помилок.
  3. Для кожного запису з перерахованих сутностей модуль створює файл: / local / migrato / <назва модуля> / <назва суті> / data- <xml id> .xml
  4. Якщо дані були видалені - у відповідному файлі проставляється атрибут deleted = true в вузлі <data>

xml   Якщо дані були видалені - у відповідному файлі проставляється атрибут deleted = true в вузлі <data>

Імпорт з * .xml-файлів (команда import)

  1. Модуль виконує розбір і імпорт налаштувань в БД.
  2. Модуль проводить перевірку даних. Робота триває тільки якщо немає помилок.
  3. Модуль читає data-файли і імпортує записи.
  4. Модуль перевіряє, чи залишилися суті з невирішеними залежностями. Якщо вони є - це помилка.
  5. Модуль видаляє файли, помічені атрибутом deleted = true.
  6. Модуль проставляє посилання в даних.
  7. Оновлення пошукового індексу, urlrewrite, скидання кешу // Адже ви не забуваєте робити все це при релізах :)?

Висновок логів попередньої команди (команда log)

Якщо при виконанні однієї з попередніх команд сталася помилка, побачити їх можна командою log. Використавши опцію --fails можна відфільтрувати всі записи, залишивши тільки повідомлення про помилки. Якщо ж вам зручніше працювати з БД, то всі помилки зберігаються в таблиці intervolga_migrato_log.

Генерація демо-контенту (команда для розробників generate)

Пам'ятайте, трава раніше була зеленішою, морозиво смачніше а модуль DEFA Tools був безкоштовним? Його генератор демо-контенту ми відтворювати, звичайно, не стали, але додати по 2 записи в кожну суті команда generate може. Команда корисна для розробників нових сутностей.

Тестування модуля (команда для розробників unittest)

Друга команда, корисна для розробників (і тестувальників). Виповнюється сценарій.

  1. export
  2. Файли XML копіюються в / local / migrato_old /
  3. import
  4. export
  5. diff папок / local / migrato / і / local / migrato_old /

Якщо все суті працюють правильно, diff буде порожнім. Якщо ж немає - це означає, що в коді суті є помилка і вона імпортується в базу неправильно.

Формат XML файлів

Синтаксис XML-файлів міграції налаштувань модулів

Синтаксис XML-файлів міграції налаштувань модулів

Вузол Батьківський вузол Опис <options> - Батьківський вузол <option> <options> Налаштування <name> <option> Назва настройки <value> <option> Значення настройки <site> <option> Сайт, для якого задано значення

Синтаксис XML-файлів міграції даних

Синтаксис XML-файлів міграції даних

Вузол Батьківський вузол Опис <data> - Батьківський вузол. Атрибут deleted каже, що дані були видалені <xml_id> <data> XML ID даних <dependency> <data> Вузол залежності <reference> <data> Вузол посилання <field> <data> Вузол простого поля <name> <dependency>
<Reference>
<Field> Назва поля <value> <dependency>
<Reference>
<Field> Значення поля

Як користуватися модулем

Щоб почати використовувати модуль необхідно на бойовому сайті створити оригінальний зліпок БД:

  1. Встановити модуль intervolga.migrato
  2. налаштувати /local/migrato/config.xml
  3. validate
    1. autofix при необхідності або ручне виправлення XML ID в БД
  4. export
  5. Додати папку / local / migrato / в git (він же у вас вже є)
  6. git commit & git push
  7. Зняти бекап з prod і розгорнути на dev1, dev2 ...

Щоб підготувати міграцію на пісочниці devX після закінчення роботи над завданням:

  1. validate
    1. autofix при необхідності або ручне виправлення XML ID в БД
  2. export
  3. git commit & git push

Виконати міграцію (реліз) на бойовому сайті:

  1. validate
    1. autofix при необхідності
  2. export (раптом на бою були невраховані в git'е зміни?)
    1. git commit при необхідності
  3. git pull
    1. вирішення конфліктів, якщо виникли
    2. git push, якщо виникли конфлікти
  4. import

Використання XML ID замість ID в коді

Допитливий читач-програміст може задати питання: як же тепер писати код, якщо використовувати ID - погано, а XML ID міграції не завжди збігається з XML ID суті?

Модуль надає API для отримання ID по XML ID:
\ Intervolga \ Migrato \ Data \ BaseData :: getPublicId ($ xmlId)

Метод використовує кешування, так що про продуктивність не варто турбуватися.

Якщо ви використовуєте константи для звернення до сутностей по ID, то вам тільки і потрібно - зробити наступну заміну.

було
було

стало
стало

А ось друга зміна прийняти буде не так просто. Візуальний редактор буса при роботі з компонентами генерує код, в якому явно фігурують "магічні" неунікальні числові ID.

Ось за таке хочеться Бітрікс від душі посварити. Генерація коду зашита дуже глибоко і кастомизировать її немає ніякої можливості. Ми не стали вигадувати хитрих способів підміни такого коду і просто ввели правило - візуальним редактором для редагування компонентів не користуємося. Програміст один раз налаштовує компонент, потім замінює ID на XML ID міграції і ніяких няш-мяш. Якщо знаєте спосіб краще - розкажіть в коментарях, з радістю приймемо на озброєння.

Виконання прикладу з інших модулів

І, наостанок, виконання загального прикладу нашим модулем. Відразу після установки перевірили всі записи на наявність зовнішніх ключів і виправили помилки:

Тепер можна створювати dev сайти для розробників - клонуємо prod і обов'язково робимо перший знімок бази даних (виконуємо команду експорт).

Після того, як кожен програміст виконає своє завдання на своєму сайті, він робить експорт. Так як зміни були зроблені тільки в ІБ модулі, то і експортувати інші модулі немає сенсу (Налаштування config файлу).

Після програміст робить Комміт експортованих файлів, і перед тим як виштовхнути файли на віддалений репозиторій необхідно перевірити, може інший програміст виконав завдання швидше (git pull).
На цьому кроці, не виключено виникнення конфлікту. Що ж, тут є 2 шляхи, дивлячись як Вам зручніше працювати. Якщо у вас git на серверах розробки, при конфлікті з'явиться таке попередження:

Відкриваєте файл, наприклад за допомогою vim (vi local / migato / iblock / type / ...) і вибираєте, хто з програмістів не бреше.

Після цього індексуєте файли і комитету.

Є ще другий шлях, якщо у вас гіт тільки на локальній машині, і синхронізуєте всі файли за допомогою Гіта, але на локальній машині. На прикладі показано виникнення конфлікту в IDE PHPStorm.

На прикладі показано виникнення конфлікту в IDE PHPStorm

Як тільки всі конфлікти дозволені, програміст повинен виштовхнути зміни на сервер.

Після того, як всі програмісти виштовхнули свої зміни, версія бази даних в системі управління версій стабілізується. Це означає, що настав час робити реліз. Після якого, щоб оновити будь-який сайт (будь то сайт для розробки або prod), досить трьох глобальний речей:

  • виконати pull
  • Перевірити config файл (які саме модулі та сутності нам потрібні)
  • Виконати імпорт даних

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

замість висновків

Інструмент для міграції змін БД життєво необхідний при відповідальної командній роботі над проектами. До сьогоднішнього дня ця задача в світі 1С-Бітрікс вирішувалася дуже погано.

Ми ж розробили промислове рішення цього завдання і віддаємо його безкоштовно всім бажаючим. Користуйтеся, пропонуйте поліпшення, беріть участь в розвитку, ми будемо раді. Щоб отримати посилання на установку модуля міграцій для Бітрікс, "поділіться" статтею в соцмережах і вкажіть посилання в форму під статтею. Посилання на репозиторій з документацією прийде вам на пошту.

Оновлення пошукового індексу, urlrewrite, скидання кешу // Адже ви не забуваєте робити все це при релізах :)?
Оновлення пошукового індексу, urlrewrite, скидання кешу // Адже ви не забуваєте робити все це при релізах :)?
Оновлення пошукового індексу, urlrewrite, скидання кешу // Адже ви не забуваєте робити все це при релізах :)?

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

Или позвоните нам по телефонам: (048) 823-25-64

Организация (обязательно) *

Адрес доставки

Объем

Как с вами связаться:

Имя

Телефон (обязательно) *

Мобильный телефон

Ваш E-Mail

Дополнительная информация: