GIT для 1C-Bitrix, как наладить процесс разработки?
У нас есть 2 площадки: тестовая и продовская. Продовская находится у заказчика, тестовая у нас. На каждой битре один ключ. Доступ к тестовой базе есть только с тестовой площадке, подрубиться извне никак. Есть репозиторий с 2 ветками на гите: developer и master соответственно. На проекте работает 2 человека: фронт и бэк. Суть проблемы в том, что неудобно вести локальную разработку, так как папка bitrix находится в гитигноре по причине своей массивности. При клоне ветки developer и создании от нее дочерней ветки все изменения производятся по факту вслепую, без print_r, console.log и прочих благ цивилизации. Попытка закинуть отдельно ядро битрикс и бэкап базы в проект не привела ровным счетом ни к чему, так как вываливается ошибка об просроченной лицензии и дальнейшем предложением эту лицензию купить. В результате разработка тормозится тем фактом, что чтобы посмотреть изменения и в случае чего внести малейший фикс, нужно запушить свои изменения, запулить их на сервере и только после этого править, и так по кругу. Выяснили, что проблема редактирования БД решается миграциями. Вопрос в следующем: как грамотно организовать локальную разработку на Bitrix через Git?
В настройках главного модуля есть галочка "Установка для разработки".
Берете папку bitrix и базу данных с прода, на них поднимаете локально, ставите галочку и работаете.
Не очень понятно почему у вас просит купить лицензию, вы не с прода взяли bitrix и бд?
Непонятно так же зачем вам 2 репозитория? Одного достаточно с ветками master и dev. От мастера создаете фича ветки и в них работаете, потом вливаете их в дев, а потом дев в мастер
Сергей, по поводу репозиториев: опечатка, подразумевалось 2 ветки в одном репо, в тексте поправил. Продублируйте свой комментарий в ответы, отмечу как решение, действительно помогло ставить bitrix именно с прода, а не с нуля, как изначально пробовали.
Один раз делаете полную копию сайта для любого из разработчиков на любую машину и разворачиваете.
Ставите галочку "версия для разработки" в настройках обновления системы.
Дальше работаете с гит как обычно.
С миграциями разобрались — молодцы.
Папку Битрикс можно практически полностью исключить из гита, за исключением папок установленных нештатных расширений и модулей, но и их можно перенести в local.
Ну можно отладочные домены дописать в настройки сайта.
Готовых примеров файла .gitignore для Битрикс полно в сети.
Подскажите, как производят процессы?
Например есть прод биртрикса. С него сняли копию каталога и БД, развернули дев. На деве трудятся разрабы.
На проде покупатели совершают покупки регулярно. То есть, базы расходятся, как возможно и некоторые файлы каталога.
Как наработки разработчиков, в том числе и БД, отправляют в прод? Какие инструменты? Предположим, прод и дев на разных физически серверах.
Tech, можно заливать с помощью deployer, например, а настроить гитхаб или гитлаб таким образом чтобы через CICD можно было из нужного коммита заливать автоматически, либо по команде руками.
Можно коннектится на нужный сервер и гитом подтягивать изменения из коммитов уже на нём.
Тут кто во что горазд и кому как удобнее.
Tech, так вам соответствие полное бд никчему же.
Достаточно обеспечить соответствие структур БД или, в контексте Битрикс, соответствие перечня свойств и параметров иб.
Это можно решить миграциями, например.
Вам полностю расписать?
Tech, всё что вы заполняли тестово, если это не касается структуры, только данных, на основу накатывать не нужно, зачем на основе тестовые данные? В большинстве случаев всё что вы делаете базы данных не касается.
Если это стандартный функционал, то скорее всего структура данных будет неизменна, максимум что понадобится это изменить настройки и/или сделать обмен с учетной системой.
Если это ваш модуль со своими таблицами, ORM, тогда всё идёт по стандартной схеме, через обновление модулей, как написано в доках, вам нужно каждый апдейт оформлять как патч, и если там меняется структура базы данных, а данные нужно оставить, тогда пишутся скрипты, которые выполняют переход с одной структуры данных на другую.
Как наработки разработчиков, в том числе и БД, отправляют в прод?
Tech, миграциями (в Маркетплейсе есть модуль). Если разработчику неохота писать миграцию (у нас демократия в этом плане) и ситуация позволяет, то можно изменения в БД провести на проде, и перенести базу на дев.
Примеры:
создаётся инфоблок или HL блок. Он в любом случае будет создан. Создание на проде позволяет избежать расхождения ID
свойства заказа - можно создать на проде и деактивировать
При этом ничто не мешает разработчику сначала потыкаться на dev, попробовать разные варианты и прийти к окончательному решению.
Александр Маджугин, похоже, Вы мало работали с Битриксом. ID групп пользователей влияет. ID цен влияет. ID инфоблоков и HL блоков влияют на пользовательские поля (UF) и на вызовы компонентов. ID свойств влияют, если Вы храните их в отдельных таблицах и используете миграции.
И это только то, что я вспомнил сходу.
Михаил Ливач, я работаю с битриксом с 2011 года.
Если у вас на что то влияют все эти ID - то это очень плохой код. Его надо чинить.
Никаких ID в коде быть не должно. В идеальном случае в коде допускается вообще только одна цифра - 2, для размерности монитора.
Александр Маджугин, если у Вас есть опыт решения перечисленных мной проблем без извращений - поделитесь, пожалуйста, всем читающим будет полезно.
Или специфика Вашего опыта такова, что Вы с этим не сталкивались? Допускаю, что такое возможно - буквально на днях была содержательная беседа с подобным человеком.
Михаил Ливач, задайте конкретный вопрос - в чем сложность не использовать ID?
Ну предположим у вас есть какая-то выборка, или компонент, в котором нужно указать ID инфблока - найдите инфоблок по его символьному коду и получите его id. К примеру так: https://github.com/Suntechnic/xBxx/blob/master/Hel... (метод getIdByCode)
Александр Маджугин, я же Вам привёл конкретные примеры, в которых использовать не ID, а что-то другое, в Битриксе проблемно. Инфоблоков в моём списке не было, это Ваша фантазия.
В моём списке были пользовательские поля, у которых привязки к сущностям выглядят как HLBLOCK_7 , IBLOCK_2_SECTION и тому подобное.
И я специально добавил уточнение: "без извращений". Конечно, можно ту же цену получить по коду, а потом уже подставлять ID там, где нужно. Но тогда вы создаёте проблемы с Эрмитажем.
Простой
