Перейти к содержимому
BXWiki

Настройки проекта - файл ядра, опции модуля, разные стенды

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

Решение

Читаем настройки ядра из кода:

use Bitrix\Main\Config\Configuration;


$cache = Configuration::getValue('cache');            // весь раздел настроек
$vendor = Configuration::getInstance()->get('vendor'); // и свой раздел тоже
$apiUrl = $vendor['api_url'] ?? 'https://example.org/api';
// файл настроек читается раньше базы: он доступен даже при недоступной базе

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

Отделяем значения стенда дополняющим файлом:

// /bitrix/.settings_extra.php - лежит на каждом стенде свой, в репозиторий не идёт
return [
    'vendor' => ['value' => ['api_url' => 'https://test.example.org/api']],
    'exception_handling' => ['value' => ['debug' => true]],
];
// значения этого файла перекрывают одноимённые из основного

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

Заводим свои опции модуля:

use Bitrix\Main\Config\Option;


Option::set('vendor.shop', 'api_key', $key);
$key = Option::get('vendor.shop', 'api_key', '');      // третий аргумент - значение по умолчанию
$limit = (int)Option::get('vendor.shop', 'batch', 50); // опции всегда возвращают строку

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

Убираем секреты из репозитория:

/bitrix/.settings.php        - в репозитории, без паролей
/bitrix/.settings_extra.php  - на каждом стенде свой, в списке игнорируемых
/bitrix/php_interface/dbconn.php - подключение старого ядра, тоже вне репозитория

Ключ, однажды попавший в репозиторий, считается известным посторонним. Удаление его следующим коммитом не помогает: он остаётся в истории, и менять придётся сам ключ, а не файл.

Настройки стоит читать в одном месте решения, а не россыпью по всему коду. Обёртка над чтением даёт значения по умолчанию и то место, куда потом добавляется проверка заполненности.

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

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

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

Типичные проблемы

Пароль от базы оказался в репозитории.

Файл настроек ядра версионируется вместе с подключением. Подключение и ключи выносят в дополняющий файл стенда.

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

Файл настроек приехал с другого стенда вместе с кодом. Такие файлы в выкладку не входят вовсе.

Настройки модуля пропали после переустановки.

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

Новое значение настройки не применяется.

Прочитанное значение осело в кэше или в статическом поле класса. Настройки читают через одну обёртку и сбрасывают кэш при изменении.

На боевом сайте включена отладка.

Значение задано в общем файле, а не в файле стенда. Отладку включают только дополняющим файлом.

Частые вопросы

Где хранить настройку: в файле или в опции?

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

Как задать настройку для конкретного сайта?

Опции принимают идентификатор сайта отдельным аргументом. Файл настроек общий для всего проекта.

Можно ли править файл настроек руками на боевом?

Можно, но правку никто не увидит в истории. Лучше выкладывать её тем же путём, что и код.

Что делать с ключом, уже попавшим в репозиторий?

Считать его известным и выпустить новый. Чистка истории помогает только при уверенности, что копий репозитория нет.

Смежное

Первоисточник