У вас есть несколько вариантов здесь. Выбор, который вы выберете, будет зависеть от вашей ситуации и процессов, которые вы используете для развертывания в вашей организации. Конечно, у каждого решения есть свои плюсы и минусы, поэтому вам нужно взвесить каждое из них в соответствии с вашей ситуацией. Я лично использовал каждое из следующего:
Ваш первый вариант заключается в создании общего хранилища на сетевом диске для хранения вашего контента. Эта функция встроена в сервер IIS (6.0+). Это позволяет вашему сайту иметь единственное место для вашего веб-кода, что делает развертывание одной ксерокопией. Преимущества этого подхода в том, что вы можете сделать свой контент доступным только для чтения через стандартный общий доступ к сети. У вас должна быть надежная и избыточная сетевая инфраструктура для реализации этой опции, так как я видел некоторые проблемы, когда серверы не могут получить содержимое на некоторых серверах по той или иной причине при запуске, вызывая проблемы. IIS кэширует информацию из общего ресурса, который когда-то запускался, по ряду причин, но это помогает, если в вашей сети происходит сбой. Вы также можете использовать общую конфигурацию на уровне сервера вместо уровня приложения (см. http://learn.iis.net/page.aspx/211/shared-configuration/).
Второй вариант - реализовать решение с помощью Web Deploy 2.0 (бесплатно: см. http://www.iis.net/download/WebDeploy).. Развертывание с помощью этой среды позволяет вам создать решение, которое подходит для ваших организационных процессов легко и надежно с минимальными усилиями. Можно довольно легко создать решение для автоматического развертывания, но вам понадобятся стандарты в отношении того, как вы принимаете пакеты для развертывания от своих групп разработчиков приложений, чтобы сделать реализацию решений согласованной и многократно используемой.
Третий вариант - реализовать решение с помощью таких продуктов, как «Repliweb», которые обеспечивают синхронизацию веб-сайта и содержимого всей веб-фермы. Repliweb и аналогичные продукты имеют очень надежные варианты развертывания. Эти продукты не являются бесплатными, но предлагают преимущества, которые вам не нужно тратить на разработку "из коробки" (например, разрешение группам разработчиков развертывать приложения на основе файлов триггеров без необходимости доступа к серверам IIS или привлечения административного персонала ( Есть много вариантов для настройки развертываний.) У Microsoft был продукт, который они продавали, но сейчас он окончен и называется Application Center 2000, многие функции которого были реализованы в приведенном выше варианте WebDeploy, хотя и гораздо более практического подхода.
Четвертый вариант - разработка пользовательского решения с использованием API-интерфейсов Microsoft.Web.Administration для IIS. Этот вариант, безусловно, необходимо настраивать, но он также требует больших инвестиций в технологии и очень зависит от уровня квалификации и персонала, которому поручено развертывание приложений, и от того, существуют ли четко определенные процессы для упаковки приложений для развертывания и т. Д. Я разработал решение, использующее этот метод, который управляет фермой из 200+ серверов (разделенных на кластеры не менее чем из 4 серверов, каждый из которых находится за балансировщиками нагрузки, в каждом кластере размещается множество приложений на кластер и, таким образом, это многоуровневая среда). Это дало нам возможность иметь единый интерфейс развертывания для всей организации, в котором можно развертывать веб-приложения, а также не-веб-приложения, такие как службы Windows, и все это с минимальными усилиями. Это решение было разработано в связи с особой потребностью, поскольку Microsoft объявила об окончании срока службы продукта Центра приложений, в котором использовалась методология развертывания, основанная на API-интерфейсах приложений и параметрах командной строки. В то время у MS не было никакой замены для этого продукта, что заставило нас спросить, что нам теперь делать? Итак, мы пошли по этому пути. Я также должен отметить, что MS еще не анонсировала и не выпустила инфраструктуру WebDeploy, или мы разработали бы наше решение на основе этой платформы, упомянутой в Варианте 2 выше.
Опять же, у вас есть много вариантов на выбор, и, как уже упоминалось, они будут различаться в зависимости от того, как настроены ваши процессы и среда, и какие ограничения могут ограничивать каждый вариант (будь то стоимость, сетевые ограничения, запрещающие использование общих окон и т. Д.) .
Приветствия