Условные обозначения для файла настроек в программном обеспечении с открытым исходным кодом
Я разрабатываю приложение PHP, которому нужен доступ к базе данных, и я использую git для контроля версий. Я хочу создать файл настроек, в котором будут храниться имя пользователя, пароль и другие настройки приложения. Тем не менее, я не хочу рисковать, добавив его в свой репозиторий.
В настоящее время я управляю этим, создав файл settings.ignore.php в том же каталоге и разместив его в своем файле .gitignore.
settings.php:
<?php
$dbUser = '';
$dbPass = '';
$dbName = '';
include 'settings.ignore.php';
settings.ignore.php:
<?php
$dbUser = 'admin';
$dbPass = 'secret';
$dbName = 'database';
Это лучший или самый распространенный способ решения проблемы?
Решение
Как правило, параметры конфигурации должны храниться вне кода приложения.
Таким образом, вы можете довольно просто обновить приложение, не касаясь конфигурации. Например, взгляните на структуру папок проекта Symfony:
app/ # configuration, log files, cache
bin/ # "binaries", i.e. helper scripts for the command line
src/ # YOUR application code, i.e. code you wrote specifically for your app
vendor/ # 3RD PARTY code, i.e. Symfony and other external code
web/ # public files: images, JS, CSS, font files
Конфигурация зависит от конкретной среды и, в зависимости от того, какая она есть, находится в разных файлах:
app/config/config_dev.yml # config for your development environment
app/config/config_test.yml # config for your unit tests
app/config/config_prod.yml # config for production/target environments
app/config/config_longjon.yml # if you want, set up your own env. type
app/config/config.yml # common config for all of them, inherited
Кстати, как вы видите, Symfony не использует файлы PHP для конфигурации, но YAML (или XML). В данном случае это конечно очень важно хранить конфигурацию вне корня документа.
Я бы порекомендовал загрузить ряд широко используемых фреймворков, написанных на разных языках, возможно, прочитайте их документацию, чтобы увидеть, как они справляются с этой категорией вопросов.
Они, как правило, очень много думали об этом, и многие опытные разработчики, как правило, были вовлечены.
Другие решения
Других решений пока нет …