Управление подверсией конфигурационными файлами проекта

Я не знаю, является ли это «лучшей практикой», но я справляюсь именно так, и это работает очень хорошо. У меня есть несколько приложений, и у каждого из них есть отдельный файл конфигурации для производственной, промежуточной среды и среды разработки. Конфиги называются web.config, stage.config и dev.config. Все три находятся под контролем версий. Приложение ожидает и использует файл web.config для получения параметров конфигурации. Как часть наших сценариев сборки и развертывания NANT, вызываемых круиз-контролем, в зависимости от развертываемой среды соответствующая конфигурация переименовывается в web.config и развертывается.

Надеюсь, это поможет.

Keeping multiple files in source control can be tricky. We use a home brew configuration tool that reads a system environment variable and from that reads a matching config file and then modifies a shared configuration file. I can't say it's a great solution, but it works.

For years, and many different, successful projects, I just don't version the system or developer specific config file. Sometimes it is just database access info, or a few vital paths or whatever. Narrow it down to as little as possible. Don't feel bad about not versioning that info. This has been done with every number between 2 and 5 developers on several projects and it has never caused confusion, problems or debate on real world projects.

На мой взгляд, держать все файлы конфигурации под контролем версий бесполезно. В одном из моих проектов у нас были файлы конфигурации, созданные с помощью cmake для нескольких платформ (из одного шаблона). У каждого разработчика в нашей команде был собственный настроенный дополнительный скрипт для создания необходимых конфигураций.