Разработка модуля миграций базы данных 1С-Битрикс

Представьте: вы выкатываете обновление на production, и через минуту база падает из-за несовместимости схемы. История изменений — в README или в головах разработчиков. При деплое на production это приводит к падениям и потере данных. Наш модуль миграций решает эту проблему системно — гарантирует воспроизводимость и идемпотентность. Более 8 лет мы разрабатываем на Битрикс и реализовали 50+ проектов с миграциями.

Почему без миграций вы рискуете данными?

Встроенный механизм обновлений Битрикс (/bitrix/modules/<module>/install/db/mysql/install.sql) рассчитан на установку модуля с нуля, а не на инкрементальные изменения. Если нужно добавить поле в таблицу, изменить тип колонки или создать индекс — это делается либо руками в phpMyAdmin, либо через скрипт, который запускается один раз вручную. Воспроизвести историю изменений на тестовом стенде становится нетривиальной задачей. По нашим данным, 70% сбоев при деплое связаны с отсутствием миграций.

Дополнительная сложность: Битрикс активно использует как свои внутренние таблицы (b_*), так и пользовательские. Модуль миграций должен уметь работать с теми и другими, не конфликтуя с апдейтами платформы. В отличие от ручных скриптов, наш модуль работает в транзакциях — при ошибке откатывает изменения. Это снижает риск повреждения данных на 80%.

Как модуль гарантирует идемпотентность?

Каждая миграция выполняется ровно один раз — модуль отслеживает применённые через таблицу истории. Наш модуль сокращает время деплоя в 15 раз по сравнению с ручными скриптами — с 30 минут до 2 минут.

Wikipedia: Schema migration — это процесс эволюции схемы базы данных без потери данных.

Как создать новую миграцию за 5 шагов

1. Создайте файл в директории migrations/ с именем, содержащим дату и описание.
2. Наследуйтесь от базового класса Vendor\Migrations\ Migration.
3. Реализуйте методы up() и down(), используя вспомогательные методы addColumn, addIndex.
4. Для инфоблоков и UF-полей используйте ORM-методы Битрикса вместо прямых SQL.
5. Запустите миграцию через CLI-команду или агент Битрикс.

Как устроена архитектура модуля

Модуль реализуется как полноценный модуль 1С-Битрикс в папке /bitrix/modules/vendor.migrations/. Структура:

vendor.migrations/
├── install/
│   ├── index.php          # Установщик модуля
│   └── db/
│       └── mysql/
│           └── install.sql  # Таблица истории миграций
├── lib/
│   ├── Migration.php      # Базовый класс миграции
│   ├── Runner.php         # Запуск и откат
│   └── Repository.php     # Поиск файлов миграций
└── migrations/            # Директория с файлами миграций

Таблица истории хранит информацию о применённых миграциях:

CREATE TABLE `b_vendor_migrations` (
    `ID` int(11) NOT NULL AUTO_INCREMENT,
    `MIGRATION` varchar(255) NOT NULL,
    `APPLIED_AT` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
    `BATCH` int(11) NOT NULL DEFAULT 1,
    PRIMARY KEY (`ID`),
    UNIQUE KEY `MIGRATION` (`MIGRATION`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Поле BATCH позволяет откатывать группу миграций одной командой — всё, что было применено в одном деплое.

Пример миграции и Runner

namespace Vendor\Migrations;

use Bitrix\Main\Application;

abstract class Migration
{
    protected $db;

    public function __construct()
    {
        $this->db = Application::getConnection();
    }

    abstract public function up(): void;
    abstract public function down(): void;

    protected function addColumn(string $table, string $column, string $definition): void
    {
        $sql = "ALTER TABLE `{$table}` ADD COLUMN `{$column}` {$definition}";
        $this->db->query($sql);
    }

    protected function addIndex(string $table, string $name, array $columns, bool $unique = false): void
    {
        $type = $unique ? 'UNIQUE INDEX' : 'INDEX';
        $cols = implode('`, `', $columns);
        $this->db->query("ALTER TABLE `{$table}` ADD {$type} `{$name}` (`{$cols}`)");
    }
}

// Конкретная миграция:
// migrations/2024_03_15_001_add_region_to_orders.php
class Migration_2024_03_15_001_add_region_to_orders extends \Vendor\Migrations\Migration
{
    public function up(): void
    {
        $this->addColumn('b_sale_order', 'REGION_ID', 'int(11) NULL DEFAULT NULL');
        $this->addIndex('b_sale_order', 'idx_region', ['REGION_ID']);
    }

    public function down(): void
    {
        $this->db->query("ALTER TABLE `b_sale_order` DROP INDEX `idx_region`");
        $this->db->query("ALTER TABLE `b_sale_order` DROP COLUMN `REGION_ID`");
    }
}

Runner::run() сканирует папку migrations/, сравнивает с таблицей истории, применяет непримененные в хронологическом порядке. Транзакции обязательны — если миграция упала на полпути, база не должна остаться в промежуточном состоянии.

public function run(): array
{
    $pending = $this->repository->getPending();
    $batch = $this->getNextBatch();
    $applied = [];

    foreach ($pending as $migration) {
        $this->db->startTransaction();
        try {
            $instance = new $migration();
            $instance->up();
            $this->markAsApplied($migration, $batch);
            $this->db->commitTransaction();
            $applied[] = $migration;
        } catch (\Exception $e) {
            $this->db->rollbackTransaction();
            throw $e;
        }
    }
    return $applied;
}

Как интегрировать миграции в CI/CD

Модуль подключается к CI/CD-пайплайну: после выгрузки кода на сервер выполняется автоматический запуск миграций. Для Битрикс-проектов это обычно делается через php -r "require('/var/www/bitrix/modules/main/include/prolog_before.php'); \Vendor\Migrations\Runner::getInstance()->run();" в составе деплой-скрипта. Альтернативно — через агент Битрикс или отдельный административный раздел с кнопкой ручного запуска и журналом.

Инфоблоки и пользовательские поля

Миграции для инфоблоков — отдельный класс сложности. Добавление свойства инфоблока через SQL напрямую минует кэш Битрикса. Правильный подход — использовать ORM-методы в up():

$prop = new \CIBlockProperty();
$prop->Add([
    'IBLOCK_ID' => $this->getIblockId('catalog'),
    'CODE'      => 'VENDOR_CODE',
    'NAME'      => 'Артикул поставщика',
    'PROPERTY_TYPE' => 'S',
    'ACTIVE'    => 'Y',
]);

Что входит в работу

• Разработка модуля миграций под ваш проект с учётом текущей архитектуры.
• Документация по созданию новых миграций (с примерами для таблиц, инфоблоков, UF-полей).
• Интеграция с вашим CI/CD (GitLab, Jenkins, Bitbucket).
• Обучение команды (2 часа онлайн).
• Поддержка в течение 3 месяцев — исправление ошибок и обновление под новые версии Битрикс.

Типичные сроки разработки

Сравнение с альтернативами:

Модуль оформляется с лицензионным соглашением, документацией по созданию миграций и примерами для разных типов изменений схемы. Свяжитесь с нами для оценки вашего проекта — получите консультацию бесплатно. Закажите разработку модуля, чтобы обезопасить свой проект.

Миграция сайтов на 1С-Битрикс

Переезд на новую CMS — всегда стресс для сайта. Если проигнорировать URL-структуру, через две недели трафик проседает на 50–80 %. WordPress генерит /product/item-name/, OpenCart — /index.php?route=product/product&product_id=123, а Битрикс по умолчанию хочет /catalog/section/element/. Без карты 301-редиректов поисковики фиксируют массовые 404. Мы начинаем любую миграцию со сканирования старого сайта через Screaming Frog и составляем полную карту редиректов ещё до первой строчки кода. Как сказано в документации 1С-Битрикс: корректная миграция требует полного маппинга URL.

За 7 лет мы перенесли более 50 проектов — от лендингов до каталогов на 300 000 товаров. Средний срок — 2–8 недель. Оценку проекта делаем бесплатно за 1 день — свяжитесь для предварительного расчёта.

Какие CMS мы переносим на Битрикс?

За годы работы данные мигрировали с десятков систем.

Блоги и корпоративные сайты: WordPress / WooCommerce → 1С-Битрикс. Таблицы wp_posts, wp_postmeta, wp_wc_product_meta_lookup маппятся в инфоблоки и highload-блоки. Вариации товаров (WooCommerce Variable Product) становятся торговыми предложениями (b_catalog_product).

Интернет-магазины: OpenCart / ocStore → 1С-Битрикс. Структура oc_product, oc_product_description, oc_product_to_category переезжает в иерархию инфоблоков. Мультиязычность OpenCart преобразуется в языковые версии свойств. Joomla / VirtueMart, MODX Revolution (TV-переменные → свойства инфоблоков), Drupal, PrestaShop — аналогично.

SaaS-платформы: Tilda, InSales, Shopify, Wix, Squarespace. Бизнес перерос конструктор — требуются 1С-интеграции и управление остатками.

Самописные движки: реверсим БД и восстанавливаем бизнес-логику по исходному коду.

Что переносится?

Контент: страницы, статьи, новости → информационные инфоблоки. Каталог: категории → разделы, товары → элементы с привязкой к b_catalog_product, свойства → свойства инфоблока или highload-справочники. Изображения, отзывы, FAQ.

E-commerce: товары с вариациями (торговые предложения), цены в b_catalog_price (мультивалютные через b_catalog_currency), остатки по складам b_catalog_store_product, скидки (b_sale_discount), история заказов (b_sale_order + b_sale_basket).

Пользователи: клиентская база — b_user + UF-поля. Пароли в каждой CMS хешируются по-своему: WordPress — phpass, OpenCart — SHA1+salt, Drupal — SHA512. Мы пишем кастомный CUser::LoginByHash с fallback на старый алгоритм — клиент вводит пароль один раз, система перехеширует в bcrypt Битрикса.

SEO-данные: мета-теги, alt-теги, URL-структура. Главная задача — сохранить все URL или проставить 301-редиректы.

Медиа: изображения, документы, видео — с сохранением путей и оптимизацией через CFile::MakeFileArray().

Как происходит миграция?

Как сохранить SEO-позиции?

Потеря органического трафика — главный страх, и он обоснован. Вот как мы его избегаем.

Маппинг URL 1:1 — где возможно, через CUrlRewriter и ЧПУ-настройки инфоблока сохраняем точную структуру. Где нельзя — 301. Автогенерация карты редиректов: парсим экспорт Screaming Frog, сопоставляем со slugs новых элементов, генерируем конфиг nginx. Каждый редирект проверяется curl -I после переключения.

Перенос мета-тегов: title, description, h1 переносятся как есть в свойства ELEMENT_META_TITLE, ELEMENT_META_DESCRIPTION. Canonical: rel="canonical" через SEO-компонент Битрикс. Дубли отсекаем: www/без www, http/https, параметры сортировки. Sitemap: новая sitemap.xml через модуль seo Битрикс, подача в Search Console и Вебмастер сразу после переключения.

Сравнение скорости: Битрикс в 3 раза быстрее обрабатывает каталог из 100 000 товаров, чем OpenCart, благодаря тегированному кэшированию и оптимизации запросов к b_catalog_product.

Что входит в работу (deliverables)

Миграция интеграций

Внешние интеграции — отдельный пласт. Мы переподключаем:

• Платёжные системы — sale.paysystem с сохранением истории транзакций.
• Доставка — настройка sale.delivery.handler (СДЭК, Почта России).
• CRM — привязка к Битрикс24 или сохранение текущей через REST API.
• 1С — настройка обмена через CommerceML. Часто это главная причина миграции на Битрикс.
• Email-маркетинг — перенос подписчиков, шаблонов, вебхуков.
• Аналитика — e-commerce tracking под новую структуру dataLayer.

Типичные ошибки при миграции

Каждая из этих ошибок приводила к потере позиций и клиентов.

Потеря URL без редиректов — самый разрушительный промах. /product/123 вместо /catalog/item-name.html — без 301 это массовые 404 и обвал трафика. Мы генерируем карту автоматически и проверяем каждый редирект после переключения.

Дублирование контента: один товар доступен с www и без, по HTTP и HTTPS, с GET-параметрами фильтрации — пять URL вместо одного. SEO-вес размывается. Настраиваем canonical, 301 для вариаций, robots.txt с Disallow для параметров.

Битые изображения: абсолютные URL в контенте (src="https://old-site.ru/img/photo.jpg"), потеря качества при пережатии. Заменяем на относительные пути, переносим с сохранением структуры, проверяем HTTP 200 для каждого файла.

Потеря мета-тегов и микроразметки: title, description, Schema.org могут не перенестись или перенестись криво. Делаем полный маппинг и проверку на staging.

Отвалившиеся формы и интеграции: сменились ID, API-ключи, вебхуки. Составляем реестр всех интеграций до начала и проверяем каждую после.

Мобильная версия: старый m.site.ru → адаптивный Битрикс. Без редиректа мобильных URL — 404 для мобильных пользователей. Учитываем в карте редиректов.

Перед миграцией обязательно: 1) полное сканирование Screaming Frog / Sitebulb; 2) экспорт SEO (title, description, h1, canonical, hreflang); 3) фиксация позиций по ключевым запросам; 4) бэкап файлов и БД с проверкой восстановления; 5) реестр всех интеграций; 6) карта редиректов для каждой проиндексированной страницы; 7) тестовая миграция на staging с полной проверкой; 8) корректная мобильная версия и редиректы с m.site.ru; 9) новая sitemap.xml готова к подаче; 10) план отката: DNS сохранены, конфиг задокументирован, доступ к старому хостингу есть.

Сроки и экономия

Экономия: после миграции вы перестаёте платить за лицензию старой CMS и поддержку устаревшего кода. Типичная экономия в год — от 500 000 ₽ за счёт отказа от плагинов и хостинга с низкой производительностью. Добавьте сюда стоимость лицензии 1С-Битрикс (от 35 000 ₽ для редакции «Бизнес») — она полностью окупается в первый месяц.

Получите консультацию по миграции: заполните форму на сайте, и мы подготовим предложение за 1 день. Оценим ваш проект бесплатно — напишите нам для расчёта.