Чтобы вручную не переносить настройки и не забывать изменения на тестовых, требуется мигратор. Есть готовое хорошее решение: intervolga.migrato. У него две основные команды: экспорт и импорт.
Порядок работы разработчиком при выполнении поставленной задачи:
- Создаем нужную ветку в гит
- Меняем как надо файлы
- Меняем настройки в панели битрикс, как надо для задачи
- В консоли пишем
php migrato export(все настройки экспортируются в файл в /local/migrato/) - Далее коммитим файлы в гит (в том числе файл экспорта настроек)
- Всё, нужные нам настройки привязаны к ветке в гит.
Если надо, переключаем ветку в мастер и пишем php migrato import
Так у нас все настройки откатились к версии мастера
Возможно такое:
- Вы создали в новой ветке инфоблок
- Заполнили инфоблок нужными данными
- Экспортнули настройки мигратором
- Переключили гит на мастер ветку
- Импортнули состояние битрикса в мастере
- После снова переключились на нужную ветку
- Через мигратор восстановили состояние
В чем подвох? У вас пропали все записи в инфоблоке. Почему? Потому что мигратор не работает с записями. Он увидел новый инфоблок - эспортнул его. Инфоблок надо удалить - удалил. А что там бало внутри - ему безразлично. Поддерживаемые сущности
Решение: не заполнять инфоблоки реальными данными на этапе разработки (когда инфоблок еще может быть удален мигратором), либо экспортировать данные через штатный механизм Битрикс в отдельный файл.
При деплое:
- Идем на прод
- Пишем
php migrato export - Переносим всё с прода на тестовый в мастер
- Сливаем на тестовом нужную ветку задачи в мастер.
- Пишем
php migrato importдля актуализации настроек на тестовом сайте. - Переносим мастер с правками на прод.
- На проде пишем
php migrato import - Получаем прод с актуальными файлами и актуальными настройками!
Так как в процессе переноса правок с одного сайта на другой у сущностей могут меняться ID, к ним привязываться не стоит.
В модуле есть готовый функционал на этот случай (он с кешированием, дополнительной нагрузки сильно не будет):
\Intervolga\Migrato\Data\Module\Iblock\Iblock::getPublicId(внешний код инфоблока);
Intervolga\Migrato\Data\Module\Iblock\Property::getPublicId(внешний код свойства);
Переходим в главную ветку проекта. Например:
git checkout master
В корне сайта прописать:
git clone https://github.com/intervolga/intervolga.migrato bitrix/modules/intervolga.migrato
ln -s bitrix/modules/intervolga.migrato/tools/run.php migrato
В панели в установленных решениях (/bitrix/admin/partner_modules.php?lang=ru) установить модуль "Модуль миграций"
Далее снова команды:
git add local/migrato/
git add migrato
git commit -m "Создание мигратора"
php migrato autofix
Если автофикс где-то не справляется и появляются ошибки, пишем слудующую команду и исправляем вручную
php migrato log --fails
Проверяем состояние:
php migrato validate
Когда ошибок уже нет:
php migrato export
git add local/migrato/
git commit -m "Актуальные настройки Битрикс"
При установке мигратора, если у сущности не указан внешний код, он задается случайным образом. Из этого получаем, что если устанавливать мигратор на два одинаковых сайта, файлы экспорта у нас получатся разные (так как разные внешние коды). В итоге при слиянии сайтов через мигратор много сущностей дублируется.
Решение: устанавливать мигратор на 1 сайт. После уже второй сайт делать из его копии, чтобы на втором сайте были те же внешние коды.
Либо решение 2 (на ваш страх и риск, решение сырое и не оттестированное): использовать форк https://github.com/MashinaMashina/intervolga.migrato Там я постарался уменьшить случайную генерацию кодов и добавить логику.
Подробнее про мигратор: https://www.intervolga.ru/blog/projects/bitrix-database-migration-new-way/