Миграции данных в Битрикс

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.
Миграции данных в Битрикс
Один из самых острых вопросов при разработке на Битрикс - это миграции базы данных.

Какие же способы облегчить эту задачу есть на данный момент?

Способ 1 - никак

Оставляем перенос данных на откуп разработчика. Как правило, в таких ситуациях ID инфоблока указывается в коде числом.
Вводим правило "при создании инфоблока на площадке разработчика одновременно должен быть создан инфоблок на боевом сервере".

Правило перестаёт работать при выполнении одного из двух условий:
 - рост команды и, как следствие, появление новичка, которому выдаются ключи к базе данных. Кровью написаны строки о том, как джуниоры случайно уничтожают БД "боевого" сервера.
 - усталость и/или несогласованность работы нескольких разработчиков, возможно - личностный конфликт. Даже идеальный разработчик может хорошо провести выходные, с печальными последствиями для своей концентрации.

При бесконечном доверии разработчикам можно оставить такую схему деплоя изменений в базе данных.

Способ 2 - ресурсозатратный, но рабочий

Решение на базе консольных утилит mysqldump, grep и diff. Оно позволяет отслеживать изменения на уровне базы данных.

Суть же способа следующая:
- перед началом работы над задачей делается дамп бд с помощью mysqldump
- после окончания работы делается дамп бд
- затем с помощью скрипта, использующего grep и diff (утилита, позволяющая проходиться регулярными выражениями по тексту и утилита, сравнивающая содержимое двух файлов) выделяются произошедшие изменения
- изменения кладутся в .sql файл, который отсматривает и правит разработчик
- .sql файл выкатывается на боевой сервер и запускается там.

К плюсам можно отнести возможность автоматизации процессов выкатки.

Способ может дать серьёзные сбои при отличии id записей, и толком не работает, когда одни сущности ссылаются на другие. Но необходимость выкатывать подобные изменения бывает не так часто.

Способ 3 - рекомендованный Битриксом

Можно на каждую задачу писать специальный скрипт, описывающий с помощью API Битрикса, какие изменения должны быть внесены.
Например, создать новое свойство инфоблока
     // добавим пользовательское свойство инфоблоку.
     $arFields = array(
          "ENTITY_ID" => "IBLOCK_".$iBlockChild."_SECTION",
          "FIELD_NAME" => "UF_NOT_VIEW_DATE",
          "USER_TYPE_ID" => "boolean",
          "EDIT_FORM_LABEL" => Array("ru"=>"Не показывать дату", "en"=>"NOT VIEW DATE"),
          );
     $obUserField  = new CUserTypeEntity;
     $iUserFieldId = $obUserField->Add($arFields);
     echo "New UserTypeEntity: ".$iUserFieldId."\n";
Это сложно: скрипт нужно написать, выкатить и запустить. Так гораздо сложнее, чем работать с приветливой админкой Битрикса.

Но есть и ряд преимуществ:
 - разработчики учат API Битрикса (что они и так, в общем-то, должны делать) и открывают для себя ранее неизвестные методы. Реально зафиксировано повышение квалификации благодаря этому решению!
 - всегда известно, кто и что конкретно поправил.
 - есть возможность разделить зоны ответственности и повысить дисциплину.
 - разработчик трижды думает, прежде чем вносить изменения на боевой сервер, и его мысли может понять и подхватить другой разработчик.

Способ 4 - экспериментальный

Есть ребята, которые пишут сейчас свой модуль миграций. Пишут уже долго и мучительно и написали что-то только для инфоблоков, и то он обрабатывает не все ситуации. Правда на выходе наиболее чистый "код" миграции. 
Подробнее об их модуле можно почитать на гитхабе.

Жирный минус только один: поддержка только модуля инфоблоков.
В остальном - это очень интересное направление, которое бы стоило поддержать самому 1С-Битрикс.

Вместо послесловия

Как-то раз сотрудники Битрикса обмолвились, что они работают над полноценными миграциями, но "это в такой глубокой альфа-версии, что пока и говорить об этом рано". Пока что нам остаётся только ждать и мечтать.
О чём мечтать? Например о таких решениях: