Как вы справляетесь со строками подключения при развертывании сайта ASP.NET?

Question

В настоящее время наши тестовые и производственные базы данных находятся на одном сервере, но с разными именами. Развертывание означало редактирование Web.config для изменения всех строк подключения для правильной базы данных. Шаг, который я слишком часто забываю ...

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

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

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

Answer 1

Используйте Web Deployment Project и обновите файл wdproj (это просто файл MSBuild), добавив некоторые задачи после сборки, чтобы вывести правильный файл .config. Я сохраняю web.config и web.release.config, затем использую это в файле wdproj:

<Target Name="AfterBuild">
    <Copy Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\web.release.config" DestinationFiles="$(OutputPath)\web.config" />
    <Delete Files="$(OutputPath)\web.release.config" />
</Target>

Дополнительная информация

Более простое решение, которое нравится некоторым, - это использование свойство configSource appSettings и connectionStrings и затем никогда не перезаписывать этот файл на рабочем сервере.

Answer 2

У меня обычно есть три отдельных веб-конфига: один для моей машины для разработки, один для контроля качества и один для производства. Разрабатываемый соединяется с моей локальной базой данных SQL (которая защищена извне) и является файлом по умолчанию web.config. Другие называются web-prod.config и web-qa.config. После публикации я удаляю ненужные мне два и переименовываю правильный в web.config. Если я забуду, приложение ломается при первой попытке доступа к базе данных, поскольку конфигурация по умолчанию ссылается на ту, к которой оно не может добраться.

Поскольку IIS отказывается обслуживать файл с именем .config, я уверен, что все они заканчиваются на .config вместо, скажем, web.config-prod или web.config-qa.

Answer 3

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

Для SQL Server выберите Диспетчер конфигурации SQL Server> Конфигурация собственного клиента SQL> Псевдонимы> Создать новый псевдоним.

Вы можете сделать то же самое с Oracle с помощью файла tnsnames.

Answer 4

Вот еще одна вещь, которую вы можете попробовать:

Используя диспетчер конфигурации SQL Server, создайте псевдоним БД для своей базы данных разработки, чтобы файл web.config мог быть одинаковым как на вашей машине разработки, так и на рабочем сервере.

Answer 5

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

Answer 6

Я был в нескольких местах, где храню их в реестре.

Возможно, сейчас есть более сложные способы сделать это, но большая часть кода, над которым я работал с наследием 1.0 / 1.1, хранит строки в реестре.

Реестр имеет несколько преимуществ

1. Он не позволяет людям развертывать код в неправильных местах, так как на компьютерах, которые не настроены должным образом, будут отсутствовать ключи
2. Это устраняет проблему, из-за которой разработчик случайно упаковывает файл web.config со строками подключения для разработчиков (после чего яростно звонит посреди ночи, когда выясняется, что сисадмин поздней ночи не вернулся до предыдущего файла web.config, и разработчик не знает и не вызывает производственные строки)
3. Это ограничивает возможность хакера получить строку подключения, загрузив web.config с компьютера. Кроме того, реестр имеет больше уровней безопасности, чем файловая система.

Answer 7

Я делал это так часто, что сделал web.config на производственном сервере только для чтения.

Answer 8

имеют папки среды с отдельными конфигами для каждой среды

развернуть правильный для окружающей среды

Answer 9

Я недавно склонялся к манипулированию конфигурацией на сервере непрерывной интеграции. Это связано с тем, что у нас были проблемы с несколькими файлами web.config, web.qa.config, web.production.config, которые сохраняли 95% файла, который должен быть одинаковым в синхронизации.

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

Мы используем nant, так что это файл .build, в котором есть xmlpoke для установки debug = "false", изменения строк подключения и всего, что нужно изменить в канареечной копии и упаковочной копии web.config.

Развертывание машины сборки называется «канарейка», потому что она умрет первой, если возникнет проблема.

Answer 10

Задача такого типа - именно то, для чего предназначены события сборки. Думайте о строительстве как о создании для определенной цели, любая конкретная конфигурация цели должна быть сделана там. (с обычной оговоркой, что всегда есть некоторые исключения из правила)