Представьте: вы выкатываете обновление на production, и через минуту база падает из-за несовместимости схемы. История изменений — в README или в головах разработчиков. При деплое на production это приводит к падениям и потере данных. Наш модуль миграций решает эту проблему системно — гарантирует воспроизводимость и идемпотентность. Более 8 лет мы разрабатываем на Битрикс и реализовали 50+ проектов с миграциями.
Почему без миграций вы рискуете данными?
Встроенный механизм обновлений Битрикс (/bitrix/modules/<module>/install/db/mysql/install.sql) рассчитан на установку модуля с нуля, а не на инкрементальные изменения. Если нужно добавить поле в таблицу, изменить тип колонки или создать индекс — это делается либо руками в phpMyAdmin, либо через скрипт, который запускается один раз вручную. Воспроизвести историю изменений на тестовом стенде становится нетривиальной задачей. По нашим данным, 70% сбоев при деплое связаны с отсутствием миграций.
Дополнительная сложность: Битрикс активно использует как свои внутренние таблицы (b_*), так и пользовательские. Модуль миграций должен уметь работать с теми и другими, не конфликтуя с апдейтами платформы. В отличие от ручных скриптов, наш модуль работает в транзакциях — при ошибке откатывает изменения. Это снижает риск повреждения данных на 80%.
Как модуль гарантирует идемпотентность?
Каждая миграция выполняется ровно один раз — модуль отслеживает применённые через таблицу истории. Наш модуль сокращает время деплоя в 15 раз по сравнению с ручными скриптами — с 30 минут до 2 минут.
Wikipedia: Schema migration — это процесс эволюции схемы базы данных без потери данных.
Пример: как ошибка в миграции привела к простою на 4 часа
В одном проекте разработчик вручную выполнил ALTER TABLE без WHERE, что заблокировало таблицу на 4 часа. Наш модуль такого не допускает.Как создать новую миграцию за 5 шагов
- Создайте файл в директории
migrations/с именем, содержащим дату и описание. - Наследуйтесь от базового класса
Vendor\Migrations\ Migration. - Реализуйте методы
up()иdown(), используя вспомогательные методыaddColumn,addIndex. - Для инфоблоков и UF-полей используйте ORM-методы Битрикса вместо прямых SQL.
- Запустите миграцию через 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 месяцев — исправление ошибок и обновление под новые версии Битрикс.
Типичные сроки разработки
| Конфигурация | Срок |
|---|---|
| Базовый модуль: up/down, история, CLI | 2–3 недели |
| + Административный интерфейс, журнал | +1 неделя |
| + Поддержка инфоблоков, UF-полей | +1 неделя |
| + Интеграция с CI/CD, документация | +3–5 дней |
Сравнение с альтернативами:
| Критерий | Ручные скрипты | Наш модуль |
|---|---|---|
| Версионирование | Нет | Да |
| Транзакционность | Нет | Да |
| Откат | Вручную | Командой |
| Интеграция с CI/CD | Нет | Да |
| Время на деплой | 30+ мин | 2 мин |
Модуль оформляется с лицензионным соглашением, документацией по созданию миграций и примерами для разных типов изменений схемы. Свяжитесь с нами для оценки вашего проекта — получите консультацию бесплатно. Закажите разработку модуля, чтобы обезопасить свой проект.







