Новости
- Міграції бази даних в 1С-Бітрікс: швидко, правильно, надійно Якщо Ви розробляєте проекти на 1С-Бітрікс...
- команди модуля
- Перевірка XML ID (команда validate)
- Автоматичне виправлення помилок XML ID (команда autofix)
- Експорт в * .xml-файли (команда export)
- Імпорт з * .xml-файлів (команда import)
- Генерація демо-контенту (команда для розробників generate)
- Тестування модуля (команда для розробників unittest)
- Формат XML файлів
- Синтаксис XML-файлів міграції даних
- Як користуватися модулем
- Використання XML ID замість ID в коді
- Виконання прикладу з інших модулів
- замість висновків
- Міграції бази даних в 1С-Бітрікс: швидко, правильно, надійно
- конфігурація модуля
- команди модуля
- Перевірка XML ID (команда validate)
- Автоматичне виправлення помилок XML ID (команда autofix)
- Експорт в * .xml-файли (команда export)
- Імпорт з * .xml-файлів (команда import)
- Генерація демо-контенту (команда для розробників generate)
- Тестування модуля (команда для розробників unittest)
- Формат XML файлів
- Синтаксис XML-файлів міграції даних
- Як користуватися модулем
- Використання XML ID замість ID в коді
- Виконання прикладу з інших модулів
- замість висновків
- Міграції бази даних в 1С-Бітрікс: швидко, правильно, надійно
- конфігурація модуля
- команди модуля
- Перевірка XML ID (команда validate)
- Автоматичне виправлення помилок XML ID (команда autofix)
- Експорт в * .xml-файли (команда export)
- Імпорт з * .xml-файлів (команда import)
- Генерація демо-контенту (команда для розробників generate)
- Тестування модуля (команда для розробників unittest)
- Формат XML файлів
- Синтаксис XML-файлів міграції даних
- Як користуватися модулем
- Використання XML ID замість ID в коді
- Виконання прикладу з інших модулів
- замість висновків
Міграції бази даних в 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> Регулярний вираз для виключення налаштувань з міграцій
команди модуля
Для усунення проблем з таймаут сервера (і щоб надати теплу лампову атмосферу) вся робота з модулем після установки винесена в командний рядок. Точка входу: <папка модуля> /intervolga.migrato/tools/run.php (в прикладах для стислості буде позначена як run.php).
Інтерфейс модуля в командному рядку
Синтаксис простий:
$ Php run.php команда [опції]
Доступні команди:
- validate (перевірка XML ID)
- autofix (автоматичне виправлення помилок XML ID)
- export (експорт даних з БД в XML)
- import (імпорт даних з XML в БД)
- log (висновок логів останньої запущеної команди)
Сервісні команди (для розробників нових сутностей):
- generate (генерація демо-контенту)
- unittest (тестування модуля)
Доступні опції:
- -W або --win (змінити кодування на win-1251)
- -U або --utf (змінити кодування на UTF-8)
- -F або --fails (розширений висновок помилок після виконання команди)
- -v (короткий звіт по роботі команди)
- -vv (детальний звіт по роботі команди)
Перевірка XML ID (команда validate)
Модуль читає config.xml і перевіряє, щоб у всіх примірників сутностей були задані коректні XML ID. Команда нічого не змінює в БД. Критерії коректного XML ID:
- Не порожній.
- Чи не цілком числовий.
- Потрапляє під регулярний вираз /^[a-z0-9\-_#.]+$/i (допустимі літери латинського алфавіту, цифри, тире, підкреслення, решітка, точка).
- XML ID не повинен повторюватися в межах суті.
Автоматичне виправлення помилок XML ID (команда autofix)
Виправлення помилок XML ID - відповідальний крок, тому і винесено в окрему команду. Увага: процес може привести до модифікації БД. Для всіх знайдених помилок XML ID викликається генератор XML_ID, що створює унікальний код суті.
Експорт в * .xml-файли (команда export)
- Модуль записує поточні настройки всіх перерахованих модулів в файли. Файли складаються в / local / migrato / <назва модуля> /option.xml.
- Модуль перевіряє XML ID. Робота триває тільки якщо немає помилок.
- Для кожного запису з перерахованих сутностей модуль створює файл: / local / migrato / <назва модуля> / <назва суті> / data- <xml id> .xml
- Якщо дані були видалені - у відповідному файлі проставляється атрибут deleted = true в вузлі <data>
Імпорт з * .xml-файлів (команда import)
- Модуль виконує розбір і імпорт налаштувань в БД.
- Модуль проводить перевірку даних. Робота триває тільки якщо немає помилок.
- Модуль читає data-файли і імпортує записи.
- Модуль перевіряє, чи залишилися суті з невирішеними залежностями. Якщо вони є - це помилка.
- Модуль видаляє файли, помічені атрибутом deleted = true.
- Модуль проставляє посилання в даних.
- Оновлення пошукового індексу, urlrewrite, скидання кешу // Адже ви не забуваєте робити все це при релізах :)?
Висновок логів попередньої команди (команда log)
Якщо при виконанні однієї з попередніх команд сталася помилка, побачити їх можна командою log. Використавши опцію --fails можна відфільтрувати всі записи, залишивши тільки повідомлення про помилки. Якщо ж вам зручніше працювати з БД, то всі помилки зберігаються в таблиці intervolga_migrato_log.
Генерація демо-контенту (команда для розробників generate)
Пам'ятайте, трава раніше була зеленішою, морозиво смачніше а модуль DEFA Tools був безкоштовним? Його генератор демо-контенту ми відтворювати, звичайно, не стали, але додати по 2 записи в кожну суті команда generate може. Команда корисна для розробників нових сутностей.
Тестування модуля (команда для розробників unittest)
Друга команда, корисна для розробників (і тестувальників). Виповнюється сценарій.
- export
- Файли XML копіюються в / local / migrato_old /
- import
- export
- diff папок / local / migrato / і / local / migrato_old /
Якщо все суті працюють правильно, diff буде порожнім. Якщо ж немає - це означає, що в коді суті є помилка і вона імпортується в базу неправильно.
Формат XML файлів
Синтаксис XML-файлів міграції налаштувань модулів
Вузол Батьківський вузол Опис <options> - Батьківський вузол <option> <options> Налаштування <name> <option> Назва настройки <value> <option> Значення настройки <site> <option> Сайт, для якого задано значення
Синтаксис XML-файлів міграції даних
Вузол Батьківський вузол Опис <data> - Батьківський вузол. Атрибут deleted каже, що дані були видалені <xml_id> <data> XML ID даних <dependency> <data> Вузол залежності <reference> <data> Вузол посилання <field> <data> Вузол простого поля <name> <dependency>
<Reference>
<Field> Назва поля <value> <dependency>
<Reference>
<Field> Значення поля
Як користуватися модулем
Щоб почати використовувати модуль необхідно на бойовому сайті створити оригінальний зліпок БД:
- Встановити модуль intervolga.migrato
- налаштувати /local/migrato/config.xml
- validate
- autofix при необхідності або ручне виправлення XML ID в БД
- export
- Додати папку / local / migrato / в git (він же у вас вже є)
- git commit & git push
- Зняти бекап з prod і розгорнути на dev1, dev2 ...
Щоб підготувати міграцію на пісочниці devX після закінчення роботи над завданням:
- validate
- autofix при необхідності або ручне виправлення XML ID в БД
- export
- git commit & git push
Виконати міграцію (реліз) на бойовому сайті:
- validate
- autofix при необхідності
- export (раптом на бою були невраховані в git'е зміни?)
- git commit при необхідності
- git pull
- вирішення конфліктів, якщо виникли
- git push, якщо виникли конфлікти
- 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.
Як тільки всі конфлікти дозволені, програміст повинен виштовхнути зміни на сервер.
Після того, як всі програмісти виштовхнули свої зміни, версія бази даних в системі управління версій стабілізується. Це означає, що настав час робити реліз. Після якого, щоб оновити будь-який сайт (будь то сайт для розробки або 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> Регулярний вираз для виключення налаштувань з міграцій
команди модуля
Для усунення проблем з таймаут сервера (і щоб надати теплу лампову атмосферу) вся робота з модулем після установки винесена в командний рядок. Точка входу: <папка модуля> /intervolga.migrato/tools/run.php (в прикладах для стислості буде позначена як run.php).
Інтерфейс модуля в командному рядку
Синтаксис простий:
$ Php run.php команда [опції]
Доступні команди:
- validate (перевірка XML ID)
- autofix (автоматичне виправлення помилок XML ID)
- export (експорт даних з БД в XML)
- import (імпорт даних з XML в БД)
- log (висновок логів останньої запущеної команди)
Сервісні команди (для розробників нових сутностей):
- generate (генерація демо-контенту)
- unittest (тестування модуля)
Доступні опції:
- -W або --win (змінити кодування на win-1251)
- -U або --utf (змінити кодування на UTF-8)
- -F або --fails (розширений висновок помилок після виконання команди)
- -v (короткий звіт по роботі команди)
- -vv (детальний звіт по роботі команди)
Перевірка XML ID (команда validate)
Модуль читає config.xml і перевіряє, щоб у всіх примірників сутностей були задані коректні XML ID. Команда нічого не змінює в БД. Критерії коректного XML ID:
- Не порожній.
- Чи не цілком числовий.
- Потрапляє під регулярний вираз /^[a-z0-9\-_#.]+$/i (допустимі літери латинського алфавіту, цифри, тире, підкреслення, решітка, точка).
- XML ID не повинен повторюватися в межах суті.
Автоматичне виправлення помилок XML ID (команда autofix)
Виправлення помилок XML ID - відповідальний крок, тому і винесено в окрему команду. Увага: процес може привести до модифікації БД. Для всіх знайдених помилок XML ID викликається генератор XML_ID, що створює унікальний код суті.
Експорт в * .xml-файли (команда export)
- Модуль записує поточні настройки всіх перерахованих модулів в файли. Файли складаються в / local / migrato / <назва модуля> /option.xml.
- Модуль перевіряє XML ID. Робота триває тільки якщо немає помилок.
- Для кожного запису з перерахованих сутностей модуль створює файл: / local / migrato / <назва модуля> / <назва суті> / data- <xml id> .xml
- Якщо дані були видалені - у відповідному файлі проставляється атрибут deleted = true в вузлі <data>
Імпорт з * .xml-файлів (команда import)
- Модуль виконує розбір і імпорт налаштувань в БД.
- Модуль проводить перевірку даних. Робота триває тільки якщо немає помилок.
- Модуль читає data-файли і імпортує записи.
- Модуль перевіряє, чи залишилися суті з невирішеними залежностями. Якщо вони є - це помилка.
- Модуль видаляє файли, помічені атрибутом deleted = true.
- Модуль проставляє посилання в даних.
- Оновлення пошукового індексу, urlrewrite, скидання кешу // Адже ви не забуваєте робити все це при релізах :)?
Висновок логів попередньої команди (команда log)
Якщо при виконанні однієї з попередніх команд сталася помилка, побачити їх можна командою log. Використавши опцію --fails можна відфільтрувати всі записи, залишивши тільки повідомлення про помилки. Якщо ж вам зручніше працювати з БД, то всі помилки зберігаються в таблиці intervolga_migrato_log.
Генерація демо-контенту (команда для розробників generate)
Пам'ятайте, трава раніше була зеленішою, морозиво смачніше а модуль DEFA Tools був безкоштовним? Його генератор демо-контенту ми відтворювати, звичайно, не стали, але додати по 2 записи в кожну суті команда generate може. Команда корисна для розробників нових сутностей.
Тестування модуля (команда для розробників unittest)
Друга команда, корисна для розробників (і тестувальників). Виповнюється сценарій.
- export
- Файли XML копіюються в / local / migrato_old /
- import
- export
- diff папок / local / migrato / і / local / migrato_old /
Якщо все суті працюють правильно, diff буде порожнім. Якщо ж немає - це означає, що в коді суті є помилка і вона імпортується в базу неправильно.
Формат XML файлів
Синтаксис XML-файлів міграції налаштувань модулів
Вузол Батьківський вузол Опис <options> - Батьківський вузол <option> <options> Налаштування <name> <option> Назва настройки <value> <option> Значення настройки <site> <option> Сайт, для якого задано значення
Синтаксис XML-файлів міграції даних
Вузол Батьківський вузол Опис <data> - Батьківський вузол. Атрибут deleted каже, що дані були видалені <xml_id> <data> XML ID даних <dependency> <data> Вузол залежності <reference> <data> Вузол посилання <field> <data> Вузол простого поля <name> <dependency>
<Reference>
<Field> Назва поля <value> <dependency>
<Reference>
<Field> Значення поля
Як користуватися модулем
Щоб почати використовувати модуль необхідно на бойовому сайті створити оригінальний зліпок БД:
- Встановити модуль intervolga.migrato
- налаштувати /local/migrato/config.xml
- validate
- autofix при необхідності або ручне виправлення XML ID в БД
- export
- Додати папку / local / migrato / в git (він же у вас вже є)
- git commit & git push
- Зняти бекап з prod і розгорнути на dev1, dev2 ...
Щоб підготувати міграцію на пісочниці devX після закінчення роботи над завданням:
- validate
- autofix при необхідності або ручне виправлення XML ID в БД
- export
- git commit & git push
Виконати міграцію (реліз) на бойовому сайті:
- validate
- autofix при необхідності
- export (раптом на бою були невраховані в git'е зміни?)
- git commit при необхідності
- git pull
- вирішення конфліктів, якщо виникли
- git push, якщо виникли конфлікти
- 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.
Як тільки всі конфлікти дозволені, програміст повинен виштовхнути зміни на сервер.
Після того, як всі програмісти виштовхнули свої зміни, версія бази даних в системі управління версій стабілізується. Це означає, що настав час робити реліз. Після якого, щоб оновити будь-який сайт (будь то сайт для розробки або 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> Регулярний вираз для виключення налаштувань з міграцій
команди модуля
Для усунення проблем з таймаут сервера (і щоб надати теплу лампову атмосферу) вся робота з модулем після установки винесена в командний рядок. Точка входу: <папка модуля> /intervolga.migrato/tools/run.php (в прикладах для стислості буде позначена як run.php).
Інтерфейс модуля в командному рядку
Синтаксис простий:
$ Php run.php команда [опції]
Доступні команди:
- validate (перевірка XML ID)
- autofix (автоматичне виправлення помилок XML ID)
- export (експорт даних з БД в XML)
- import (імпорт даних з XML в БД)
- log (висновок логів останньої запущеної команди)
Сервісні команди (для розробників нових сутностей):
- generate (генерація демо-контенту)
- unittest (тестування модуля)
Доступні опції:
- -W або --win (змінити кодування на win-1251)
- -U або --utf (змінити кодування на UTF-8)
- -F або --fails (розширений висновок помилок після виконання команди)
- -v (короткий звіт по роботі команди)
- -vv (детальний звіт по роботі команди)
Перевірка XML ID (команда validate)
Модуль читає config.xml і перевіряє, щоб у всіх примірників сутностей були задані коректні XML ID. Команда нічого не змінює в БД. Критерії коректного XML ID:
- Не порожній.
- Чи не цілком числовий.
- Потрапляє під регулярний вираз /^[a-z0-9\-_#.]+$/i (допустимі літери латинського алфавіту, цифри, тире, підкреслення, решітка, точка).
- XML ID не повинен повторюватися в межах суті.
Автоматичне виправлення помилок XML ID (команда autofix)
Виправлення помилок XML ID - відповідальний крок, тому і винесено в окрему команду. Увага: процес може привести до модифікації БД. Для всіх знайдених помилок XML ID викликається генератор XML_ID, що створює унікальний код суті.
Експорт в * .xml-файли (команда export)
- Модуль записує поточні настройки всіх перерахованих модулів в файли. Файли складаються в / local / migrato / <назва модуля> /option.xml.
- Модуль перевіряє XML ID. Робота триває тільки якщо немає помилок.
- Для кожного запису з перерахованих сутностей модуль створює файл: / local / migrato / <назва модуля> / <назва суті> / data- <xml id> .xml
- Якщо дані були видалені - у відповідному файлі проставляється атрибут deleted = true в вузлі <data>
Імпорт з * .xml-файлів (команда import)
- Модуль виконує розбір і імпорт налаштувань в БД.
- Модуль проводить перевірку даних. Робота триває тільки якщо немає помилок.
- Модуль читає data-файли і імпортує записи.
- Модуль перевіряє, чи залишилися суті з невирішеними залежностями. Якщо вони є - це помилка.
- Модуль видаляє файли, помічені атрибутом deleted = true.
- Модуль проставляє посилання в даних.
- Оновлення пошукового індексу, urlrewrite, скидання кешу // Адже ви не забуваєте робити все це при релізах :)?
Висновок логів попередньої команди (команда log)
Якщо при виконанні однієї з попередніх команд сталася помилка, побачити їх можна командою log. Використавши опцію --fails можна відфільтрувати всі записи, залишивши тільки повідомлення про помилки. Якщо ж вам зручніше працювати з БД, то всі помилки зберігаються в таблиці intervolga_migrato_log.
Генерація демо-контенту (команда для розробників generate)
Пам'ятайте, трава раніше була зеленішою, морозиво смачніше а модуль DEFA Tools був безкоштовним? Його генератор демо-контенту ми відтворювати, звичайно, не стали, але додати по 2 записи в кожну суті команда generate може. Команда корисна для розробників нових сутностей.
Тестування модуля (команда для розробників unittest)
Друга команда, корисна для розробників (і тестувальників). Виповнюється сценарій.
- export
- Файли XML копіюються в / local / migrato_old /
- import
- export
- diff папок / local / migrato / і / local / migrato_old /
Якщо все суті працюють правильно, diff буде порожнім. Якщо ж немає - це означає, що в коді суті є помилка і вона імпортується в базу неправильно.
Формат XML файлів
Синтаксис XML-файлів міграції налаштувань модулів
Вузол Батьківський вузол Опис <options> - Батьківський вузол <option> <options> Налаштування <name> <option> Назва настройки <value> <option> Значення настройки <site> <option> Сайт, для якого задано значення
Синтаксис XML-файлів міграції даних
Вузол Батьківський вузол Опис <data> - Батьківський вузол. Атрибут deleted каже, що дані були видалені <xml_id> <data> XML ID даних <dependency> <data> Вузол залежності <reference> <data> Вузол посилання <field> <data> Вузол простого поля <name> <dependency>
<Reference>
<Field> Назва поля <value> <dependency>
<Reference>
<Field> Значення поля
Як користуватися модулем
Щоб почати використовувати модуль необхідно на бойовому сайті створити оригінальний зліпок БД:
- Встановити модуль intervolga.migrato
- налаштувати /local/migrato/config.xml
- validate
- autofix при необхідності або ручне виправлення XML ID в БД
- export
- Додати папку / local / migrato / в git (він же у вас вже є)
- git commit & git push
- Зняти бекап з prod і розгорнути на dev1, dev2 ...
Щоб підготувати міграцію на пісочниці devX після закінчення роботи над завданням:
- validate
- autofix при необхідності або ручне виправлення XML ID в БД
- export
- git commit & git push
Виконати міграцію (реліз) на бойовому сайті:
- validate
- autofix при необхідності
- export (раптом на бою були невраховані в git'е зміни?)
- git commit при необхідності
- git pull
- вирішення конфліктів, якщо виникли
- git push, якщо виникли конфлікти
- 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.
Як тільки всі конфлікти дозволені, програміст повинен виштовхнути зміни на сервер.
Після того, як всі програмісти виштовхнули свої зміни, версія бази даних в системі управління версій стабілізується. Це означає, що настав час робити реліз. Після якого, щоб оновити будь-який сайт (будь то сайт для розробки або prod), досить трьох глобальний речей:
- виконати pull
- Перевірити config файл (які саме модулі та сутності нам потрібні)
- Виконати імпорт даних
В результаті, кожен сайт має актуальну версію бази даних з усіма змінами. Будь то видалення, створення або редагування записів з конфліктами або без, наш модуль чудово впорався з поставленими завданнями.
замість висновків
Інструмент для міграції змін БД життєво необхідний при відповідальної командній роботі над проектами. До сьогоднішнього дня ця задача в світі 1С-Бітрікс вирішувалася дуже погано.
Ми ж розробили промислове рішення цього завдання і віддаємо його безкоштовно всім бажаючим. Користуйтеся, пропонуйте поліпшення, беріть участь в розвитку, ми будемо раді. Щоб отримати посилання на установку модуля міграцій для Бітрікс, "поділіться" статтею в соцмережах і вкажіть посилання в форму під статтею. Посилання на репозиторій з документацією прийде вам на пошту.
Оновлення пошукового індексу, urlrewrite, скидання кешу // Адже ви не забуваєте робити все це при релізах :)?Оновлення пошукового індексу, urlrewrite, скидання кешу // Адже ви не забуваєте робити все це при релізах :)?
Оновлення пошукового індексу, urlrewrite, скидання кешу // Адже ви не забуваєте робити все це при релізах :)?