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

  1. Як зазвичай роблять міграції
  2. Як насправді треба робити міграції
  3. Порівняння модулів міграції з MarketPlace
  4. Міграції за допомогою модуля «міграції для розробників»
  5. Міграції за допомогою модуля «Копір: Міграція даних»
  6. Міграції за допомогою модуля «міграції схеми даних»
  7. Результат порівняння модулів міграції
  8. висновки

У традиційній схемі веб-розробки програміст має доступ до сервера і вносить зміни прямо на бойовий сайт. Так надходити можна тільки якщо на сайті немає відвідувачів, в іншому випадку схема ускладнюється: поруч з prod-сайтом з'являється dev-сайт для обкатування всіх новинок. Чим більше і складніше сайт - тим більше повинна бути команда розробників. І у кожного повинна бути своя незалежна копія сайту. Звичайна розробка змінюється командної, з'являються проблеми взаємодії, зокрема перенесення напрацювань між серверами. Для коду є універсальне рішення - системи контролю версій (VCS, Version Control System), наприклад GIT, Mercurial.

Для коду є універсальне рішення - системи контролю версій (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-сайт для тестування.


Дірок в такій схемі більше ніж у сирі Маасдам.

  • Потрібно багато часу крутого розробника для перенесення змін.
  • Програміст повинен пам'ятати про кожне зроблене їм зміна в БД і правильно його описати в звіті.
  • Якщо БД була змінена не програмістом (агент, 1С, сторонні рішення), то обчислити їх - дуже нетривіальне завдання.

Ми працювали за такою схемою останні 3 роки і всяке побачили. У 2017 році після стратегічного наради терпець увірвався і загін самогубців з двох пряморукіх програмістів відправили на пошуки / розробку чарівного інструменту об'єднання змін БД. Так як в інших CMS і CMF цей механізм називається "міграції", то і ми будемо використовувати цей термін.

Як насправді треба робити міграції

Вимоги до нового механізму озвучили керівники і техліди:

  • Налаштування. Повинна бути можливість вибору, що саме буде мігрувати (В одному проекті нам потрібні Інфоблоки, в іншому групи користувачів, а в третьому - все відразу).
  • Авторство. Зміни БД повинні фіксуватися в репозиторії. Це відмінне рішення проблеми анонімних змін в БД.
  • Автоматизація. Позбутися від ручної роботи (запис змін в ході розробки, пошук зовнішніх змін в БД, відтворення змін на іншому сервері при перенесенні).
  • Підтримка зовнішніх змін. Модуль не повинен ламатися, якщо зміни будуть внесені через 1С, вручну адміністратором при редагуванні сайту, агентом або будь-яким іншим способом.
  • Версіонування. Повинна бути можливість відкотитися з будь-якої версії БД на будь-яку іншу. При цьому код сайту і структура БД повинні відповідати один одному.

Виявилося, що в Marketplace вже були схожі за нашими вимогами рішення.

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

Порівняння модулів міграції з MarketPlace

приклад

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

У новинах є властивість "Картинки новин".

Завдання для першого програміста:

  • Видалити властивість "Картинки новин" з Інфоблоки новин.
  • Перенести слайдер на сторінку "Про компанії", (тобто змінити шаблони url шляхів)
  • Видалити ІБ "Відгуки"

Завдання для другого програміста:

  • Додати властивість "Редактор" Інфоблоки новин
  • Перекласти слайдер на ЧПУ

Завдання для техліда: об'єднати зміни з двох пісочниць на prod-сайті для тестування і демонстрації менеджеру проекту.

Міграції за допомогою модуля «міграції для розробників»

Модуль сповідує підхід "в будь-який незрозумілій ситуації пиши інсталятор". Інсталятор - це клас з двома методами: up (хильнути міграцію) та down (відповідно, відкотити міграцію). Модуль бере на себе установку / видалення файлів міграції та надає інтерфейс в панелі управління сайтом. Інсталятори зберігаються у вигляді php-файлів по шляху / local / php_interface / migrations / *.

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

Створимо файл міграції

Метод up для "Наката" і down для "відкатів" міграції:

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

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

Другий програміст паралельно робить свої інсталятори і теж відправляє їх в репозиторій.

Техлід на prod сайті робить pull. На сторінці модуля з'явилися два нових файлу міграції:

Після натискання "Встановити нові" на prod-сайті відбулися зміни.

  • Властивість "EDITOR" - склалося.
  • Властивість "PICS_NEWS" - віддалилося
  • Спочатку застосувати міграція другого розробника, змінивши шаблон посилань на ЧПУ
  • Потім шаблони посилань змінилися на розділ "* / about /".

плюси:

  • API для роботи з Інфоблоки, надане модулем.
  • Інтерфейс для застосування або відкату міграцій.
  • Часткова автоматизація процесу (для перенесення досить натиснути кнопочку).

мінуси:

  • Повна автоматизація міграції не з'явилася, всі дії все одно необхідно записувати. Але вже не текстом, а у вигляді php-коду (який ще й тестувати не завадить).
  • Не всі поля, навіть на сутності Інфоблоки, враховані.
  • Чи не відслідковуються конфлікти (зміни різними програмістами бд в одному місці).
  • Всі зміни БД повинні вноситися ТІЛЬКИ програмістом. Або ж після змін, зроблених будь-ким програміст повинен переглядати БД, і відновлювати картину місця злочину, програмуючи інсталятор.
  • API модуля працює з даними по ID, який в різних БД може відрізнятися.

Міграції за допомогою модуля «Копір: Міграція даних»

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

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

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

Щоб перенести змінену структуру Інфоблоки необхідно перейти в "Сервіси", там з'явився пункт Копір, з підпунктами для копіювання різних сутностей:

Щоб перенести змінену структуру Інфоблоки необхідно перейти в Сервіси, там з'явився пункт Копір, з підпунктами для копіювання різних сутностей:

Нашим експериментаторам потрібен пункт "Копіювання Інфоблоки".

Перший програміст:

Другий програміст:

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

  • + Додалося створене властивість-посилання на інфоблок "Співробітники".
  • - Налаштування Інфоблоки (шаблони url) не потрапили на prod.
  • - Видалення властивості ніяк не відображається на prod.

плюси:

  • Модуль платний, а значить підтримуваний.

мінуси:

  • Модуль платний, а значить платити доведеться за кожен проект.
  • Мігрувати дані можна тільки в межах одного сервера.
  • Мігрують не всі настройки Інфоблоки.
  • Нічого не відбувається з властивостями, які видалили.
  • Можна мігрувати тільки: "Інфоблоки", "Поштові події і шаблони", "Опитування", "Вебформи".

Міграції за допомогою модуля «міграції схеми даних»

На сторінці модуля є докладна для установки модуля і налаштування середовища для розробки (клонування prod сайту для розробників).

Встановили модуль, клонували prod сайт розробникам в окремі dev сайти, зробили зміни в Інфоблоки і файли самі створилися.

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

Приклад файлу:


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

Щоб застосувати оновлення, досить натиснути кнопку "Оновити".

Проблема виникла знову тільки з конфліктуючими шаблонами посилань Інфоблоки.

плюси:

  • Чітка автоматизація процесу.
  • Окремий файли змін.

мінуси

  • Відстеження тільки міграції Інфоблоки.
  • Чи не відслідковуються конфлікти змін.

Результат порівняння модулів міграції

У цій таблиці у нас відразу спойлер - можливості нашого модуля, докладніше про який ви прочитаєте в наступній статті .

Вимоги / критерії Міграції для розробників Копір: Міграція даних Міграції схеми даних Модуль ИнтерВолга Можливість вибору сутностей для міграції Так Так Ні Так Авторство змін Так Так Так Так Автоматизація міграції даних Так * Так Так Так Підтримка будь-яких змін Так Так Ні Так Версіонування Так Ні Так Так модуль попереджає про конфліктуючих зміни Ні Ні Ні Так Набір сутностей для міграції Немає обмежень ІБ, Форми, Опитування, поштові події ІБ ІБ, групи користувачів, поштові події, призначені для користувача поля, HL, культура + мови + з айти, sale, catalog На міграцію не впливає один чи це сервер або різні Так Ні Так Так

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

висновки

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

Ми дуже хотіли знайти готове рішення. З одного боку, з нашими вимогами цього не вийшло зробити. З іншого - кількість проектів на яких працює 2+ програмістів постійно зростало і терпіти вже не було сил.

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


Що вийшло - читайте в наступній статті .


Оцініть статтю:

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

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

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

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

Объем

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

Имя

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

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

Ваш E-Mail

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