Условные обозначения для файла настроек в программном обеспечении с открытым исходным кодом

Я разрабатываю приложение 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';

Это лучший или самый распространенный способ решения проблемы?

1

Решение

Как правило, параметры конфигурации должны храниться вне кода приложения.

Таким образом, вы можете довольно просто обновить приложение, не касаясь конфигурации. Например, взгляните на структуру папок проекта 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). В данном случае это конечно очень важно хранить конфигурацию вне корня документа.

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

Они, как правило, очень много думали об этом, и многие опытные разработчики, как правило, были вовлечены.

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]