Наша компания приближается к дате начала работы (и к получению даты отдела контроля качества), и я пытаюсь определить правильные операционные процессы для поддержки этого. Мое большое соображение - как избежать ада развертывания / конфигурации, который неизбежно произошел. Кто-нибудь из вас нашел хорошее решение для передачи сборок непрограммистам, чтобы они могли успешно установить и настроить его в QA, промежуточной и производственной среде?
Полная среда для нас состоит из смеси разнородных запланированных задач, служб Windows и веб-сайтов, которые можно масштабировать с помощью параллельного развертывания. К счастью, средства конфигурации последовательны. К сожалению, все это управляется с помощью файлов .NET web / app.config. По моему опыту, сотрудники QA и ops всегда портятся, пытаясь их изменить (XML удивительно сложно обрабатывать большинству людей!)
Вот варианты, которые я рассматриваю:
Использование файлов machine.config
Это то, чего я не делал на практике, но выглядит многообещающе. Если мы создадим шаблон machine.config, содержащий каждый параметр для каждого приложения, которое может варьироваться в зависимости от среды, это позволит администратору вносить все изменения в один файл и развертывать его на каждом компьютере в среде.
- Плюсы:
- Это потенциально уменьшает количество шагов, необходимых для развертывания системы
- Минусы:
- Необходимость каким-либо образом документировать изменения схемы конфигурации
- Unknowns:
- Мы используем пользовательские разделы конфигурации и другие расширения конфигурации, которые ссылаются на сборки. Требуется ли для этого установка наших сборок .NET в GAC компьютеров?
Выполнение манипуляций с конфигурационным файлом в процессе сборки
Если мы настроим QA, промежуточную и производственную среды так, чтобы они выглядели идентично нашему программному обеспечению (виртуальные серверы и локальные сети и т. Д.), QA должен иметь возможность переносить готовое программное обеспечение без изменений конфигурации непосредственно в промежуточную среду, и подготовка к производству. С этой настройкой теоретически мы могли бы передать предварительно сконфигурированные файлы QA foo.config, которые никто не должен трогать.
- Плюсы:
- Инжиниринг будет более опытным в обеспечении правильности файлов конфигурации
- Минусы:
- Для инженеров может считаться плохой практикой безопасности знать о производственных конфигурациях (плохой аргумент, ИМХО)
иметь централизованное сетевое хранилище настроек
Этот не выглядит привлекательным для меня, потому что я пробовал это тремя способами, которые в конечном итоге были неудачными:
- В предыдущей компании у нас были параметры конфигурации в базе данных, но, конечно, вы не можете поместить их все туда, так как вам нужно настроить строку подключения от до этой базы данных. Кроме того, было так же сложно убедиться, что база данных была должным образом обновлена перед развертыванием.
- Другим подходом, который мы попробовали, было создание сетевого сервиса, который работал бы как своего рода централизованный реестр. Это почти сработало, но всегда были проблемы с локальным кэшированием, гарантией того, что URL-адрес сервера конфигурации был правильно настроен, и, конечно, настройкой сервера конфигурации.
- Active Directory? Еа! Должен ли я сказать больше?
Мысли
Насколько успешно вы пользовались вариантами, которые я рассматриваю? Есть ли альтернативы этим, которые хорошо сработали для вас?