ведение файлов web.config

Question

Мне интересно узнать, как другие хранят свои файлы web.config для развернутых приложений. (при условии отсутствия механизма автоматического развертывания - это выходит за рамки этого вопроса)

Таким образом, во время разработки некоторые разработчики могут использовать преобразования web.config, создавать / публиковать свои проекты (отладка / выпуск, тестировать / использовать конфигурации), а затем развертывать все опубликованные артефакты на веб-сервере и настраивать IIS. Некоторые разработчики могут создавать / публиковать свои проекты, развертывать опубликованные артефакты на веб-сервере, настраивать IIS, а затем вручную обновлять web.configs для конкретной среды (test / live и т. Д.), В которой они развертываются.

Как только начальное развертывание выполнено и приложение запущено в производство (либо в оперативной, либо в тестовой среде), как вы будете поддерживать файлы web.config с течением времени, если, например, нужно изменить строку подключения к базе данных или ключ настроек приложения?

Используете ли вы преобразования web.config, вносите ли изменения в VS, повторно публикуете приложение, затем копируете все приложение или, возможно, только новый web.config на сервер?

Вы просто вручную вносите изменения в файл web.config на сервере?

Изменяет ли ваш контроль версий изменения web.config в контроле исходного кода, если меняются такие вещи, как строки подключения, ключи приложения и т. Д. (Не структура)?

Мне интересно знать, как другие приближаются к этому.

В настоящее время мы производим изменения в файле web.config. По мере того как мы внедряем новые функции или исправляем ошибки, мы контролируем эти изменения, а также любые изменения в файле web.config, такие как новые ключи приложения и т. Д. Если нам потребуется развернуть новую версию приложения, мы создадим резервную копию текущей версии в рабочей среде. сервер, удалите все файлы, файлы конфигурации исключений, затем скопируйте новую версию без файлов конфигурации на рабочий сервер, сохранив существующую конфигурацию. Затем вручную сравните существующую конфигурацию с той, которая имеется в управлении исходным кодом, чтобы учесть изменения в схеме.

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

Answer 1

Мы используем преобразования web.config с VS 2010.

Вы можете указать один основной файл web.config и использовать преобразования для манипулирования им в различных средах (т. Е. Изменение строк подключения к базе данных). Эти преобразования автоматически отображаются при развертывании / публикации ваших проектов.

Это также зависит от того, какой тип изменений необходимо внедрить. Хотя, как правило, наш параметр развертывания - заменять только файлы, которые были обновлены. Так что, если все, что мы изменили, это преобразование web.config.production, то это все, что развернуто.

И да, мы сохраняем все файлы web.config и их преобразования под контролем исходного кода, поскольку они являются частью приложений, которые полагаются на них.

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

Answer 2

Исходным контролем для нас является мастер-магазин. Все, что нужно изменить HAS , чтобы войти в это. Разработчики, которые пытаются обойти это путем изменения настроек конфигурации на сайтах PROD или STAGE, попадают в тупик. Если что-то идет не так, они несут ответственность за исправление любых проблем. Обычно после первой ночи они больше не делают этого. Файлы конфигурации управления исходным кодом затем встраиваются в файлы web.config и settings.config с использованием xml / xslt

В моем текущем проекте я использую web.config, который одинаков для всех сред, и использую configSource для получения настроек, специфичных для сервера

<appSettings configSource="App_Data\appsettings.config"/>

Каждая среда имеет свой собственный файл настроек

• appsettings.user1.dev.config
• appsettings.user2.dev.config
• appsettings.stage.config
• appsettings.prod.config

Сценарий выпуска пакета, который у нас есть, берет нужный файл настроек и переименовывает в appsettings.config, после чего загружается весь выпуск. Затем релиз можно пометить в системе контроля версий.