поддержка файлов web.config

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

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

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

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

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

Вы контролируете версии в Интернете. config изменяется в системе управления версиями, если меняются такие вещи, как строки подключения, ключи приложений и т.д. (не структура)?

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

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

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

8
задан Jeremy 2 February 2011 в 05:32
поделиться