Наша компания приближается к дате «запуска» (и у нее есть дата для отдела контроля качества), и я пытаюсь определить правильные операционные процессы для поддержки этого. Я очень серьезно думаю о том, как избежать неизбежного ада развертывания / настройки. Нашел ли кто-нибудь из вас хорошее решение для передачи сборок непрограммистам, чтобы они могли успешно установить и настроить их в среде контроля качества, промежуточной и производственной среде?
Полная среда для нас состоит из смеси разнородных запланированных задач, служб Windows и веб-сайтов, все из которых можно масштабировать путем параллельного развертывания. К счастью, средства настройки согласованы. К сожалению, все это управляется через файлы .NET web / app.config. По моему опыту, специалисты по контролю качества и операторы всегда портят их, пытаясь изменить их (XML на удивление сложен для большинства людей!)
Вот варианты, которые я рассматриваю:
Использование файлов machine.config
На практике я этого не делал, но это выглядит многообещающим. Если мы создадим шаблон machine.config, содержащий все настройки для каждого приложения, которые могут различаться в зависимости от среды, это позволит администратору вносить все изменения в один файл и развертывать его на каждом компьютере в среде.
- Pros:
- This potentially reduces the number of steps necessary to deploy a system
- Cons:
- Having to somehow document configuration schema changes
- Unknowns:
- We make use of custom config sections and other configuration extensions that reference assemblies. Would this require us to install our .NET assemblies in the machines' GACs?
Выполнение манипуляций с файлом конфигурации в процессе сборки
Если мы настроим среду контроля качества, промежуточную и производственную среды так, чтобы они выглядели идентичными нашему программному обеспечению (виртуальные серверы, локальные сети и т. Д.), QA должен иметь возможность передавать готовое программное обеспечение без изменений конфигурации непосредственно в промежуточную среду и переходить к производственной среде. . При такой настройке теоретически мы могли бы передать предварительно настроенные QA файлы foo.config, которые никому не нужно трогать.
- Pros:
- Engineering would be more adept at ensuring that configuration files are valid
- Cons:
- It may be considered poor security practice for engineering to be aware of production configurations (a poor argument, IMHO)
Иметь централизованный сетевой репозиторий настроек
Этот вариант мне не кажется привлекательным, потому что я пробовал это тремя способами, которые в конечном итоге потерпели неудачу:
- В предыдущей компании у нас были параметры конфигурации в базе данных, но, конечно, вы не можете поместить их все туда, поскольку вам нужно настроить строку подключения к этой базе данных. Кроме того, было так же сложно обеспечить правильное обновление базы данных перед развертыванием.
- Другой подход, который мы пробовали, заключался в создании сетевой службы, которая работала бы как своего рода централизованный реестр. Это почти сработало, но всегда были проблемы с локальным кешированием, с обеспечением правильной настройки URL-адреса сервера конфигурации и, конечно же, с настройкой сервера конфигурации.
- Active Directory? Фу! Нужно ли мне сказать больше?
Мысли?
Насколько успешно вы использовали варианты, которые я рассматриваю? Есть ли какие-нибудь альтернативы этим, которые вам понравились?
