В представленной схеме есть одно неудобство: нужно исключать из репозитория "чужие" файлы. Как ни странно, с точки зрения проекта "чужими" файлами являются файлы продукта - они изменяются не разработчиками проекта, а приходят "снаружи" в виде обновлений. Неудобство заключается в том, что нельзя просто исключить папку /bitrix/ - в ней могут находиться в том числе файлы проекта - модули, компоненты, шаблоны сайта и т.д. В итоге файл .hgignore приобретает избыточный вид:[spoiler]
/bitrix/activities/bitrix/ /bitrix/admin /bitrix/cache /bitrix/components/bitrix/ /bitrix/gadgets/bitrix /bitrix/image_uploader /bitrix/images /bitrix/js /bitrix/managed_cache /bitrix/stack_cache /bitrix/modules/advertising /bitrix/modules/bitrix.sitecommunity ... /bitrix/modules/xdimport /bitrix/modules/xmpp /bitrix/modules/.htaccess /bitrix/otp /bitrix/sounds /bitrix/template/ /bitrix/themes /bitrix/tmp /bitrix/tools /bitrix/wizards/bitrix /bitrix/[^/]*\.php$ /upload /bitrix/php_interface /bitrix/panel/ /bitrix/updates/ /bitrix/fonts/ |
Самое обидное, что Битрикс иногда выпускает новые модули или создает новые папки. Тогда приходится добавлять их в исключения.
Чтобы сделать жизнь разработчиков проектов удобнее, мы решили в рамках работ по новому ядру вынести основные файлы проекта из папки /bitrix в папку /local. Это позволит изолировать изменяющиеся файлы проекта от папки продукта. По сути, в исключения достаточно будет добавить одну папку /bitrix.
Какие папки обрабатываются в /local?
activities - действия БП;
components - компоненты;
gadgets - гаджеты рабочего стола;
modules - модули;
php_interface - init.php, папка user_lang;
templates - шаблоны сайтов, шаблоны компонентов, шаблоны страниц.
При обработке папок приоритет всегда у /local перед /bitrix. Это означает, что если в /local/templates/ и /bitrix/templates/ будут находиться шаблоны сайта с одинаковым названием, то подключится шаблон из /local.
Мы уверены, что это нововведение позволит более эффективно разрабатывать проекты.
Да, доступно это с версии 14 (в настоящий момент в альфе).
Но, насколько я понимаю, такая логика будет только при подключении нового ядра и с новыми компонентами, которые уже должны быть корректно написаны в этом плане, поэтому старым проектам ничего не грозит? Там всё будет подключаться по-старому, никаких принудительных переносов разработок в локал не потребуется?
Я не имел ввиду падение проекта, а в плане разработки - необходимость переписывания путей, буде кто использует не очень красивую практику. Касается не только компонентов, но и шаблонов и т.п.
В "Пересоздание правил обработки адресов" таже проблема, также затрагивается папка /local/. Дело в том, что в ней очень много файлов и процессе пересоздания завершается с ошибкой и слетает ЧПУ
Места в репозитариях проектов не жалко, поэтому держу весь /bitrix/ там (за исключением кешей, конечно).
В этом случае просто протолкнув изменения файлов ядра с дева на прод вы убьёте прод!!!
А то учитывая, что в БД изменения вносятся ежеминутно сотнями людей на большом проекте это становится проблематичным вычленить что отслеживать, что нет. И вот БД думали тупо реплицировать, а изменения накатывать руками (ну например обновили дев, посмотрели, обновили прод).
P.S. только у нас там не мускаль, а оракл, но может какие аналоги найду... главное принцип организации подобрать.
1. Делаем копию основной БД для дальнейшего сравнения и переименовываем её $DB_NAME_production
3. Сравниваем структуру обновлённой и скопированной ранее ДБ при помощи mysqldbcompare (), вырезая и заменяя некоторые строки (см. скрипт ниже); записываем в файл миграции *.sql
4. Сравниваем данные в обновлённой и скопированной ранее ДБ при помощи pt-table-sync (), пропуская некоторые таблицы из сравнения (см. скрипт ниже); дописываем в файл миграции *.sql
Основной скрипт, производящий сравнение и записывающий файл миграции (вырезаны непринципиальные части, относящиеся к рабочему окружению)
Вот сейчас обновления ставятся как? Скачивает обновление во временную папку, оттуда файлы копируются в нужные места и если есть файл update.php, то он выполняется. Именно в этом файле затрагивается структура таблиц. После всего временная папка удаляется.
Было бы здорово, если бы инсталлятор обновления после их установки не стирал, а складывал в специальную папочку. Эту папочку сложить в git или hg. Еще нужно обучить инсталлятор искать обновления не только на битриксовом сервере, а еще в той самой папочке.
Тогда можно будет на тестовом сервере обновления скачать, проверить, затем сложить их в git. На боевом на git pull повесть хук, который после выкачки обновлений запускает инсталлятор и тот ставит обновления. То есть боевой сервер будет обновлять только через репозиторий, не придется отдельно лезть в админку и проверять обновления.
Красота?
Технически, как мне видится все вполне реализуемо.
В принципе можно заставить синхронизировать папку с обновлениями и без помощи битрикса, различными ухищрениями *nix.
Если использовать предложенную вами схему, то тогда имея 100 одинаковых лицензий, можно поддержку продлевать только для одной, а остальные подрубить к репозиторию и обновлять бесплатно.
Вот и причина. По-моему весьма очевидно.
По этой логике (одна лицензия-одно обновление) production всегда будет обновляться без тестирования, прямо на-живую?
Видимо, я так давно не обновлялся, что даже не знал об этом, черт побери!
А почему /bitrix/js/ не добавили?
Очень удобно складывать яваскрипты своих модулей в /bitrix/js/my_module_id/, по аналогии как это делают модули Битрикса
И папку /bitrix/wizards/ тоже хорошо было бы
$APPLICATION->AddHeadScript("/local/or/any/other/folder/script.js");Например - я добавил свойство через админку - создался файл миграции.
Далее я могу просто собрать эти файлы и провести миграции на другом сервере (инструмент неважен) получив аналогичную схему БД
перенес я туда свой модуль и пропало меню и настройки.
смотрим в код ядра файл admin_lib.php строка 302
финиш, забываем про свои меню.
дальше не копал ибо бессмысленно.
Была проблема с подключением шаблонов компонент (сейчас не вспомню точно ситуацию, зато решение помню точно - никаких .default в имени шаблона).
bitrix/php_interface/dbconn.php
bitrix/.settings.php
Последний особенно достает, т.к. никто не предупреждал, что он появится, пропишется в репозитории и будет перебивать настройки dbconn.php. Приходится на каждом проекте специально вычищать.
Замечены некоторые странности с папкой /local/
Во-первых, если темплейт есть только в пространстве имен local, но его нет в bitrix - то при присвоению сайту этого темплейта (который виден в выборе) пишет "ошибка шаблона" . Как только в пространстве имен bitrix появляется темплейт с таким же именем - ошибка пропадает и приоритет обработки выставляется корректный.
Аналогично с init.php. В случае, если в bitix/php_interface/ нет файла init.php - который есть в local/php_interface - сайт работает, но в некоторых случаях не обрабатывает local/php_interface/init.php.
Я вижу данный баг при работе скриптов, которые подключаются без стандартного хэдера (с prolog_before)
как от этого избавиться? С улыбкой
то проигнорируются все папки с именем bitrix, находящиеся в /local. Нужно так:
Если init.php лежит в подпапках /bitrix/php_interface/#SITE_ID#/init.php?
UPD: а папка include? Доставки там, оплаты кастомные, выгрузки.
Есть папка /local/tools/ в которой лежат разные скрипты типа добавления в корзину, отправки форм и прочие.
При аяксе с s2 английского сайта скрипт принимает данные как с s1 русского сайта. Тоесть товары попадают в корзину на s1, языковые файлы возвращают русские константы
if (isset($_REQUEST['SITE_ID']) && !empty($_REQUEST['SITE_ID'])) { if (!is_string($_REQUEST['SITE_ID'])) die(); if (preg_match('/^[a-z0-9_]{2}$/i', $_REQUEST['SITE_ID']) === 1) define('SITE_ID', $_REQUEST['SITE_ID']); } else { die(); }Как правильно определить куда устанавливать модуль и компоненты? В папку /bitrix или в /local
Поддержка local появилась аж 5 лет назад.
Если вы ориентируетесь на тех, у кого настолько старый продукт,
боюсь даже представить какой у вас в модуле легаси код с поддержкой php 5.2
создана директория local
local/
├── components
├── composer.json
├── composer.lock
├── migrations
├── modules
├── php_interface
│ ├── dbconn.php
│ ├── init.php
│ ├── project
│ └── wn
├── templates
│ └── malta
└── vendor
├── arrilot
├── autoload.php
├── bin
├── composer
├── psr
├── symfony
└── tightenco
Однако всё равно - привет!
Fatal error: require_once(): Failed opening required '/srv/www/bitrix-example.ru/bitrix/php_interface/dbconn.php' (include_path='.:/usr/share/php:/usr/share/pear') in /srv/www/bitrix-example.ru/bitrix/modules/main/start.php on line 1
Мало того в bitrix/modules/main/lib/orm/data/datamanager.php PARSER_ERROR line 77 - и это из файликов с суффиксом php5
там было $class = static::getEntityClass()::normalizeEntityClass(get_called_class());
переделал всё этакое в
$class = ${static::getEntityClass()}::normalizeEntityClass(get_called_class());
это конечно товарищи битриксписатели - залёт
зашифровали бы всё уж - а то смотришь в код и "головарука" на каждом шагу
Контекстный поиск по директории bitrix по ключу '/local/' показывает весьма скудный результат