Comments 10
Я обычно решаю эту проблему несколькими конфиг файлами.
1) Глобальный общий конфиг, который трогают только тогда, когда надо внести изменения глобально. Например, там могут храниться глобальные константы, вычисляемые пути к файлам, и т.п. (global.conf)
2) По конфигу на каждый сервер/среду где разворачивается приложение (dev.conf, prod.conf...). Обычно как раз тут живут уровни логирования, уровни кэширования, наличие/отсутствие минификации файлов (если речь о веб-проекте), и прочие радости.
3) Конфиг локального компьютера. Добавлен в гитигнор. В Readme проекта записаны правила его создания. (local.conf). Можно также добавить файл-пример, который на самом деле конфигом не является (local-sample.conf). В локальном определяется подключаемый конфиг среды, а также вносятся локальные настройки (например доступ к базе данных, хранилищу кэша, и т.п.)
При этом конфиги «наследуются». Т.е. конфиг среды частично перезаписывает глобальный конфиг, а конфиг локального компьютера перезаписывает конфиг среды. (global->dev->local). Так обеспечивается естественное желение разработчика потестить под разными уровнями логирования/кэширования и т.п.
1) Глобальный общий конфиг, который трогают только тогда, когда надо внести изменения глобально. Например, там могут храниться глобальные константы, вычисляемые пути к файлам, и т.п. (global.conf)
2) По конфигу на каждый сервер/среду где разворачивается приложение (dev.conf, prod.conf...). Обычно как раз тут живут уровни логирования, уровни кэширования, наличие/отсутствие минификации файлов (если речь о веб-проекте), и прочие радости.
3) Конфиг локального компьютера. Добавлен в гитигнор. В Readme проекта записаны правила его создания. (local.conf). Можно также добавить файл-пример, который на самом деле конфигом не является (local-sample.conf). В локальном определяется подключаемый конфиг среды, а также вносятся локальные настройки (например доступ к базе данных, хранилищу кэша, и т.п.)
При этом конфиги «наследуются». Т.е. конфиг среды частично перезаписывает глобальный конфиг, а конфиг локального компьютера перезаписывает конфиг среды. (global->dev->local). Так обеспечивается естественное желение разработчика потестить под разными уровнями логирования/кэширования и т.п.
Самый адекватный подход, я считаю. Гибкий и понятный.
Подобными слоями устроены настройки в дистрибутивах Linux; в том же git.
Подобными слоями устроены настройки в дистрибутивах Linux; в том же git.
К сожалению, дело не всегда ограничивается конфигами. Я работал на проекте, в котором для сборки на локальной машине надо было менять pom-файл (описание сборки проекта для maven). Это и было одной из предпосылок для этого поста.
А добавить в git нужный конфиг, а потом прописать его в .gitignore не решает вашу проблему?
Я не совсем понял, чем вас не устраивает второй вариант.
UFO just landed and posted this here
Мы храним все конфиги в системе управления конфигурацией (у нас ansible). Конфигурация (куча yaml файлов и jinja шаблонов) версионируется гитом, настроены разные хосты, роли, плейбуки, разная конфигурация для vagrant, production, test-server, local-development, remote-development и так далее. Нам нравится.
Sign up to leave a comment.
Хранение конфигов под версионным контролем