git и конфигурационные файлы
1,00
р.
Расскажите, кто и как решает проблему хранения конфигурационных файлов в git?
Полностью исключать их нельзя, так как проект может не собраться и/или не запуститься. В тоже время в таких файлах, как правило, хранится частная информация (данные для авторизации на внешних сервисах и т.д.).
Сейчас я размещаю в git файлы с расширением .sample (например Web.config.sample или config.yml.sample) и пишу в документации, что перед тем как запустить проект, необходимо переименовать sample-файл и заполнить его правильными значениями. Сами конфигурационные файлы я добавляю в .gitignore.
Недостатки такого подхода:
необходимо постоянно синхронизировать sample-файл c оригинальным конфигурационным файлом (добавились/изменились/удалились опции), другим пользователям нужно сделать дополнительное действие (переименовать файл), что они могут забывать делать (кто же читает документацию?)
Возможно существуют и более удачные решения. Можно ли c git придумать что-то более удобное?
Ответ
К сожалению, все так. В систему контроля версий не должны попадать конфигурационные файлы, которые не запустятся на других хостах, поэтому, как правило, ПО распространяется без реальных конфигов, и в консольные команды добавляется команда начальной конфигурации, которые могут сформировать этот файл.
Добавление обязательных конфигурационных опций на ходу - плохая идея, по крайней мере между major-версиями. Они должны иметь свое значение по умолчанию, при котором приложение продолжает вести себя так же, как и раньше. Все эти -webkit-something-tralala в CSS появились ровно оттуда же - давайте добавим эту штуку, но не будем ее пихать как готовую опцию, когда будем готовы к внедрению - внедрим, чтобы она точно не переименовывалась и не менялась потом (конкретно в CSS имена задаются стандартом, но общая идея должна быть ясна).
Впрочем, один хак я для себя нашел - весь dev-env засовывается в вагрант, где можно свободно писать любые конфиги и менять их на ходу, в результате в команде разработчиков можно свободно играться с тестовой конфигурацией.
Еще одна штука, которая помогает - это "параллельные" файлы, в которых переопределяются значения: configuration.yml содержит в себе некоторую конфигурацию, а configuration.local.yml - всего пару опций, который "берут верх" над аналогичными опциями из configuration.yml.
Полностью исключать их нельзя, так как проект может не собраться и/или не запуститься. В тоже время в таких файлах, как правило, хранится частная информация (данные для авторизации на внешних сервисах и т.д.).
Сейчас я размещаю в git файлы с расширением .sample (например Web.config.sample или config.yml.sample) и пишу в документации, что перед тем как запустить проект, необходимо переименовать sample-файл и заполнить его правильными значениями. Сами конфигурационные файлы я добавляю в .gitignore.
Недостатки такого подхода:
необходимо постоянно синхронизировать sample-файл c оригинальным конфигурационным файлом (добавились/изменились/удалились опции), другим пользователям нужно сделать дополнительное действие (переименовать файл), что они могут забывать делать (кто же читает документацию?)
Возможно существуют и более удачные решения. Можно ли c git придумать что-то более удобное?
Ответ
К сожалению, все так. В систему контроля версий не должны попадать конфигурационные файлы, которые не запустятся на других хостах, поэтому, как правило, ПО распространяется без реальных конфигов, и в консольные команды добавляется команда начальной конфигурации, которые могут сформировать этот файл.
Добавление обязательных конфигурационных опций на ходу - плохая идея, по крайней мере между major-версиями. Они должны иметь свое значение по умолчанию, при котором приложение продолжает вести себя так же, как и раньше. Все эти -webkit-something-tralala в CSS появились ровно оттуда же - давайте добавим эту штуку, но не будем ее пихать как готовую опцию, когда будем готовы к внедрению - внедрим, чтобы она точно не переименовывалась и не менялась потом (конкретно в CSS имена задаются стандартом, но общая идея должна быть ясна).
Впрочем, один хак я для себя нашел - весь dev-env засовывается в вагрант, где можно свободно писать любые конфиги и менять их на ходу, в результате в команде разработчиков можно свободно играться с тестовой конфигурацией.
Еще одна штука, которая помогает - это "параллельные" файлы, в которых переопределяются значения: configuration.yml содержит в себе некоторую конфигурацию, а configuration.local.yml - всего пару опций, который "берут верх" над аналогичными опциями из configuration.yml.
