НИКОГДА не используйте данные конфигурации жесткого кода, такие как пути файловой системы, и не пытайтесь сопоставить несколько развертываний. Это темная сторона, где много страданий.
Я считаю полезным и простым создание моих систем для поддержки нескольких конфигураций, и я регулярно добавляю файлы конфигурации в систему управления исходным кодом параллельно, но производственные данные запутаны (без реальных паролей), а разработки - шаблонные checkout не может перезаписать конфигурацию разработчика). Код всегда упакован в независимой от конфигурации манере - один и тот же двоичный файл может быть развернут где угодно.
К сожалению, большинство языковых платформ / платформ разработки не поддерживают это (в отличие от Ruby on Rails). Поэтому вы должны строить его самостоятельно, в разной степени.
В целом, основной принцип заключается в том, чтобы включить косвенность в вашу конфигурацию: укажите не конфигурацию, а то, как найти конфигурацию в вашем коде. И, как правило, вызывают несколько косвенных указаний: пользовательские, прикладные, машинные, средовые. Каждый из них должен быть найден в четко определенном месте / порядке, и среди них должен быть очень четко определенный приоритет (обычно пользователь над машиной над приложением над средой). Как правило, вы обнаружите, что каждый настраиваемый параметр имеет естественный дом в одном месте, но не стоит жестко программировать эту зависимость в ваших приложениях.
Я считаю, что ОЧЕНЬ полезно разрабатывать приложения, чтобы иметь возможность сообщать об их конфигурации и проверять ее. В большинстве случаев отсутствующий или недействительный элемент конфигурации должен привести к прерыванию приложения. Насколько это возможно, выполнить эту проверку (и прервать) при запуске = быстро потерпеть неудачу. Жесткий код по умолчанию только тогда, когда они могут надежно использоваться.
Абстрагируйте доступ к конфигурации, чтобы большая часть приложения не знала, откуда оно и как оно обрабатывается. Я предпочитаю создавать Config классы, которые предоставляют настраиваемые параметры в виде отдельных свойств (строго типизированных при необходимости), а затем я «внедряю» их в классы приложений через IOC. Не заставляйте все ваши классы приложений напрямую вызывать необработанную структуру конфигурации выбранной вами платформы; абстракция - твой друг.
В большинстве организаций корпоративного класса (Fortune 500) никто не видит конфигурации производственной (или даже тестовой) среды, кроме группы администраторов для этой среды. Файлы конфигурации никогда не развертываются в выпуске, они редактируются вручную командой администраторов. Соответствующие файлы конфигурации, конечно же, никогда не проверяются в исходном коде рядом с кодом. Административная команда может использовать контроль версий, но это их собственный закрытый репозиторий. Sarbanes-Oxley и аналогичные правила также имеют тенденцию строго запрещать разработчикам иметь общий доступ к (почти) производственным системам или любым конфиденциальным данным конфигурации. Будьте внимательны при разработке вашего подхода.
Наслаждайтесь.