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

Ответ 1

Проект Config4 * (отказ от ответственности: я его основной разработчик) не имеет встроенной интеграции с .Net или WCF, поэтому, вероятно, вам это не полезно. Однако одна из особенностей Config4 * имеет отношение к вашему вопросу: это возможность вставлять операторы if-then-else в файл конфигурации, чтобы файл мог "адаптироваться" для разных сред (таких как разработка, тестирование, прием и производство).

Возможно, вы сможете изменить эту концепцию для работы с любым синтаксисом конфигурации, который вы используете в своем проекте .Net/WCF (я не знаком с этими технологиями, но я предполагаю, что они, вероятно, используют XML-based файлы конфигурации). В частности, вы можете написать script, используя, скажем, Python, который использует операторы if-then-else для установки пар значений name = value, специфичных для среды, в map, а затем использовать некоторые операторы print для генерации набор конфигурационных файлов, адаптированных для среды. Схема псевдокода такого script:

#--------
# Set up configuration variables suitable for a specified environment
#--------
cfg["variable1"] = "default value";
cfg["variable2"] = "another default value";
if (environment == "testing") {
  cfg["variable1"] = "override default value for this environment";
  cfg["variable3"] = "value suitable for this environment";
  ...
} else if (environment == "production") {
  ...
}
#--------
# Now use print statements to generate configuration files
# Alternatively, use the _name=value_ pairs in the map to
# perform global search-and-replace on template versions of
# configuration files.
#--------
...

Для бонусных баллов script также может генерировать контрольный список тестов, которые необходимо выполнить для среды, например "Проверить, должен ли быть открыт порт брандмауэра между следующими конечными точками:..."

Ответ 2

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

http://blogs.msdn.com/b/youssefm/archive/2010/09/02/loading-wcf-client-configuration-from-different-files-with-configurationchannelfactory.aspx

Ответ 3

Мы разрабатываем распределенную систему хранения данных, и мы улавливаем многие проблемы, подобные этому, нашим модулем и интеграционными тестами, которые выполняются с каждой сборкой. Кроме того, мы используем ReviewBoard, чтобы другие разработчики могли просматривать любые изменения до того, как они будут совершены. Следующим шагом является сервер непрерывной интеграции (jenkins), который автоматически развертывает и тестирует артефакты в разных средах. Наконец, наша последняя линия защиты - это тестовое тестовое тестирование, которое работает против любой новой версии, прежде чем она будет опубликована. Конечно, очень важно иметь тестовый стенд, который максимально имитирует ваши производственные среды, но если вы всегда используете один и тот же хостинг-провайдер, это не должно быть слишком сложно.

• Относительно вашего особого случая, когда изменения в одном файле могли быть забыты в других и т.д.: Я предполагаю, что было бы легко легко проверить машину с помощью теста script.

• Неотмечаемые изменения должны быть такими же легко обнаруживаемыми, как "git diff master" или любые используемые вами vcs.

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

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

Ответ 4

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

Ответ 5

Взгляните на Config на http://www.configapp.com. Как он будет работать, вы импортируете базовый файл конфигурации, называемый web.config. Затем изнутри webapp вы создадите 4 среды, dev, test, acc и prod. Перейдите в среду разработки, создайте переменные среды и задайте значения, соответствующие среде. Вы будете поддерживать только один файл конфигурации с переменными среды. Вы можете увидеть все переменные среды и легко просмотреть различия между средами.

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

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

Мы будем поддерживать пользовательские типы, и одна вещь, которую мы можем добавить в будущем, - это тип данных порта. Часть проверки порта будет проверять, открыт ли порт. Это будет работать только с использованием плана на месте, поскольку ему необходим доступ во внутреннюю сеть. Или вы можете просто проверить его вручную. Перейдите к переменной окружения порта и отобразите все настроенные порты. Проверьте каждый порт в списке. Если порт выглядит хорошо, добавьте комментарий в Config, который он откроет, и он был проверен на определенную дату. Конфигурация предназначена для поиска и документирования.

Я, кстати, являюсь частью команды Config.

Ответ 6

Лично, если это возможно, я управляю им следующим образом: все "статические" параметры среды (соединения с базой данных, LDAP и т.д.) помещаются в конфигурационный файл сервера (не затрагиваются миграцией кода), а "динамический" в самой базе данных.

Таким образом, я только полагаюсь на команду базы данных для обновления настроек (если у вас есть доступ к базе данных, это проще). И я не имею никакого риска запускать на своем Dev PC код, указывающий на базу данных prod: D

НО У меня нет опыта Visual Studio, поэтому я не уверен, что вы можете применить что-то подобное в своем случае, но я надеюсь, что он может дать вам некоторые идеи.