Михаил Журов [6:17 PM] 
Все мы знаем и понимаем всю необходимость и важность отделения кода приложения от базы данных. 
Так если посудить, то много чего из битрикса не нужно разработчику, однако оно попадает к разработчику все равно по разным соображениям. Но что делать, если наша замечательная и любимая платформа обязывает нас поступать так, как мы поступаем? :simple_smile:
Поделитесь, как много у вас проектов, которые используют миграции для развертывания? Какие инструменты для создания миграций используете (кроме worksolutions/bitrix-module-migrations)? Каким образом осуществляется rollback (возможно ли при переходе по истории разработки в версионном контроле откатить и БД к нужной версии)? Каким образом выполняете наполнение БД тестовыми данными? С какими проблемами сталкивались при использовании миграций в битриксе? Даете ли вы в этом случае своим заказчикам доступ к настройкам дефолтных компонентов, где они сами без особого труда смогут поменять ID инфоблока, например?
Тема очень важная и щепетильная, у вас, видимо, есть опыт по решению этих проблем, и я был бы очень признателен, если бы вы поделились своим опытом на этом поприще.

Nik Samokhvalov [6:30 PM] 
worksolutions/bitrix-module-migrations не использовал. Штука интересная, но предпочитаю более проверенные решения. Был проект с yii2-мигратором (мопед не мой, но работало прекрасно). А так, использую Phinx (http://samokhvalov.info/blog/all/phinx-multiple-databases/).  В популярных инструментах и интеграция с консольным приложением, и откаты, и просмотр истории. Всё включено :simple_smile:

Контент может набиваться разными способами. Либо тупо дамп боевых табличек. Либо консольная команда, которая забьёт тестовыми данными ваши таблички. Есть даже fake-библиотеки для этого.

Никаких проблем с использованием миграций не возникало.
> Даете ли вы в этом случае своим заказчикам доступ к настройкам дефолтных компонентов, где они сами без особого труда смогут поменять ID инфоблока, например?
Я считаю, что это плохо, если клиент полезет менять айди инфоблока. Это изменение логики приложения, которое без ведома разработчиков производиться не должно. Но тем не менее, даже если такое произойдёт, ничего страшного не случится, если в настройки компонента будет сохраняться символьный код, а не идентификатор.(edited)

> Но что делать, если наша замечательная и любимая платформа обязывает нас поступать так, как мы поступаем?
@mikhail_zhurov: не поддавайтесь!


Игорь Цупко [6:36] 
>С какими проблемами сталкивались при использовании миграций в битриксе?

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

Nik Samokhvalov [6:39 PM] 
А, кстати. Из минусов Финкса: 1) в названия классов не подставляет таймстамп, поэтому приходится следить, что бы названия миграций были уникальными; 2) конфиги умеет читать только из yml-файлов.

Игорь Цупко [6:42 PM] 
>Каким образом осуществляется rollback (возможно ли при переходе по истории разработки в версионном контроле откатить и БД к нужной версии)?

Одна из интереснейших вещей касательно rollback-а вскрывается на многосерверных конфигурациях. При корректной организации процесса rollback-и не так критичны (хотя я не говорю, что их не надо писать, отнюдь!)

Смотрите:
У вас есть несколько нод. Пока вы обновляете одну ноду - остальные продолжают работать и отдавать клиенту контент. Задумайтесь: ваша база и код должны быть совместимы при переходе в рамках одной версии.
Если вам нужно переместить данные из одной таблицы в другую, вы не можете просто сделать alter table - ведь другие ноды всё ещё смотрят на старую таблицу.

Михаил Журов [6:53 PM] 
@nik.samokhvalov: А как вообще выглядит расширение для Финкса? Судя по дефолтным примерам Финкс работает на уровне таблиц. Тогда я вижу 2 варианта - либо кодить миграции именно на уровне таблиц, возможно с помощью каких-то инструментов, которые возможно предоставляет Phinx. Либо каждая миграция это пара из 2х скриптов (функций/классов/методов, нужное подчеркнуть), один из которых, грубо говоря, создает инфоблок/группу пользователя/каталог через API битрикса, а другой - удаляет. Так? Может примерчик на gist? :simple_smile:

Получается, что это и есть «те самые» скрипты миграции, которые использует битрикс при обновлениях, только с интерфейсом в виде консоли, а не веб-морды в админке, только разве что поддерживается переход в обе стороны, а не в одну. 
В этом плане инструмент от WS выглядит несколько интереснее, поскольку может «записывать» действия по добавлению новых сущностей и воспроизводить их на другой платформе (но не знаю, сможет ли этот инструмент выполнит реверс)

Ivan Tsirulev [6:53 PM] 
@may-cat Пример не совсем понятный. Имеется ввиду применение open/closed принципа в контексте модели данных? При миграции разрешено дополнять базу данных новым, но запрещено изменять существующее?(edited)
Если так, то подтверждаю — это единственный способ "выжить" в многосерверной среде.
И в этом случае нужды rollback практически нет. Любые изменения в базе будут совместимыми со старым кодом.

Nik Samokhvalov [6:56 PM] 
> один из которых, грубо говоря, создает инфоблок/группу пользователя/каталог через API битрикса, а другой - удаляет. Так?
Всё так. В одном классе описываются методы `up()` и `down()`. Разработчик должен сам прописать алгоритм создания инфоблока / группы пользователей / веб-формы / таблицы в БД. И откат.
> Получается, что это и есть «те самые» скрипты миграции, которые использует битрикс при обновлениях, только с интерфейсом в виде консоли, а не веб-морды в админке, только разве что поддерживается переход в обе стороны, а не в одну.
Разве у Битрикса есть такой инструмент? Его «инструмент», на сколько мне известно — `updater.php`. Топорный ПХП-файл, который выполнится при накатывании обновления.
Никакой версионности, никакой истории, никаких откатов…

Михаил Журов [6:59 PM] 
а я и не назвал это «инструментом» :simple_smile: я назвал их «скриптами миграции», которые рекомендует использовать команда разработки битрикса в своем курсе. Откатов - нет. История, скорее всего, есть, но у битриксоидов

Михаил Журов [7:09 PM] 
А как вы поступаете, если на ваших тестовых данных проблема не моделируется, а моделируется только на данных с прод сервера? Скажем, ошибка появляется только у группы товаров, которые находятся на 5м уровне вложенности каталога только у тех товаров, которые имеют в своем названии какой-нибудь специальный символ (но понятно, что вы этих кейсов заранее не знаете). Каким образом осуществляется перенос нужных данных с прода на дев?
или же вы не переносите ничего, а пытаетесь воспроизвести проблему у себя любой ценой, даже если не получается этого выполнить в течение длительного времени?

Nik Samokhvalov [7:19 PM] 
Как правило (по крайней мере, у меня так было), получается воспроизводятся на деве: смотришь, что есть на проблемной площадке и воссоздаёшь похожую ситуацию у себя. В противном случае, да, выкачиваем нужные таблички и моделируем окружение у себя. Но это редкость.

Ivan Tsirulev [7:21 PM] 
Полагаю, у каждой команды свой подход. Опишу наш:

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

- Каждая задача относится либо к поддержке (решение существующих ошибок), либо к разработке (расширение функциональности).

- Все задачи разработки решаются на отдельной базе данных, которая клонируется на основе продуктивной в начале цикла разработки и не обновляется до ее завершения, за редким исключением.

- Все задачи поддержки решаются на отдельной базе данных, которая не совпадает с базой данных для задач разработки (см. выше) и актуализируется продуктивными данными раз в день (иногда чаще). Под актуализацией понимается получение полной копии продуктивной базы данных.

Михаил Журов [7:22 PM] 
@nik.samokhvalov: А много ли времени отнимает операция по воспроизведению данных с прода на деве в типичной ситуации (без переноса таблиц)

Ivan Tsirulev [7:22 PM] 
При решении ошибок (задачи поддержки) надобности в сохранении данных изо дня в день нет. Потому полная переливка БД — допустимое и практичное решение.

Игорь Цупко [7:23 PM] 
Добавлю также, что значительную часть проблем можно продиагностировать, не вмешиваясь в исходный код/данные, если иметь достаточный кругозор. Этим должны заниматься специально обученные люди. И заниматься они этим могут даже на боевой базе.

Nik Samokhvalov [7:25 PM] 
Эм… Зависит от проблемы. Что-то можно воспроизвести на раз-два, что-то чуть дольше. Как верно заметил Игорь, иногда не обязательно даже запускать приложение, что бы обнаружить косяк, как бы грустно это не звучало :simple_smile:

Ivan Tsirulev [7:28 PM] 
И это подводит нас ко второй по значимости вещи при разработке — обязательному логгированию всего и вся. Наверное прозвучит экстремально, но я твердо верю, что проект можно считать поддерживаемым, только если совокупные размеры его логов превышают размер файлов и базы вместе взятых. И лучше в несколько раз.

Игорь Цупко [7:29 PM] 
а также мониторингу всего и вся, что плохо и хорошо привинчено
вообще всего
если проблема возникла, а по результатам инцидента в мониторинге или тестах не появилось проверки - с высокой вероятность что-то организовано не так.(edited)

Ivan Tsirulev [7:31 PM] 
Именно. Из опыта, результатом решения где-то половины ошибок становится не только непосредственное решение, но и появление нового мониторинга.

Михаил Журов [7:41 PM] 
@ivan.tsirulev Иван. А вы тестовую базу обновляете с прода в автоматическом режиме? Какими инструментами пользуетесь для регулярного обновления?

Ivan Tsirulev [7:43 PM] 
На простых проектах — простыми bash скриптами, которые забирают свежую резервную копию "оттуда" и разворачивают ее "здесь". На непростых проектах — лютыми самописными bash скриптами и нестандартными топологическими решениями. Непростые проекты — это где размер базы от 500 Гб и более.

Ivan Tsirulev [7:46 PM] 
Предвосхищая возможный вопрос: развертывание четырех копий БД размером в 500 Гб в среде разработки занимает от 3 часов  до 3 часов 20 минут, в зависимости от погоды. Время развертывания зависит от размера линейно. Процесс происходит ночью.