Какой метод вы используете для развертывания приложений ASP.Net в дикой природе?

Question

В настоящее время мы разворачиваем скомпилированные приложения ASP.Net, публикуя веб-сайт локально и отправляя системному администратору по электронной почте zip-файл с (обычно) длинным набором инструкций по развертыванию. Это связано с тем, что при первом развертывании приложения ASP.Net на клиенте экземпляр dev и тестовый экземпляр IIS были одинаковыми, и мы не смогли дважды развернуть сайт на одном компьютере. Это установило тон для развертывания во всех последующих проектах.

Сейчас я оцениваю наши методы развертывания и специально изучаю встроенные средства развертывания; в частности, я смотрю на пользовательские задачи установки и использую как можно больше стандартных функций установщика (в основном пользовательский интерфейс).

Во-вторых, я смотрю на слияние развертываний и автоматических обновлений.

Как вы разворачиваете программное обеспечение в своей организации? Какие инструменты вы используете, и с какими проблемами вы сталкиваетесь чаще всего?

Answer 1

У нас есть выделенные серверы DEV, TEST, STAGE и PRODUCTION.

У нас также есть специальная сборочная машина с круиз-контролем.

Круиз-контроль настроен для сборки Continuous Integration, которая запускается после регистрации кода. Он также настроен для отдельных задач разработки, QA, Stage и Production.

Для развертывания в разработке код сначала извлекается из SVN и создается, затем папка «Precompiled Web» копируется на веб-сайт разработки, а проект веб-службы копируется на сервер приложений разработки. Круиз-контроль также настроен для «маркировки» исходного кода перед началом сборки, чтобы мы могли воспроизвести сборку позже или перейти от тега, если нам нужно выполнить оперативное исправление.

Для развертывания в QA файлы копируются с машин разработки на машины QA.

Аналогично, для развертывания в Stage файлы копируются с компьютеров QA на компьютеры Stage.

Наконец, для развертывания в производство файлы снова копируются с компьютеров Stage на компьютеры производства.

Для настройки каждой среды у нас есть специальный инструмент, который является частью задачи круиз-контроля в каждой среде, которая изменяет строки подключения, «debug = true | false», «customErrors = Off | RemoteOnly» и другие параметры, относящиеся к среде.

Таким образом, каждая среда может быть развернута нажатием кнопки на панели круиз-контроля.

Одно предостережение: у нас в настоящее время настроен пароль рабочей базы данных в конфигурационном файле Cruise Control ... было бы неплохо перенести его в другое место!

Наконец, позвольте мне добавить, что, несмотря на то, что наши производственные машины находятся в выделенном хостинге, серверы доступны с нашего компьютера Cruise Control, что упрощает производственное развертывание. Единственный шаг вручную - зашифровать файлы web.config и удалить файл «AppOffline.html», который выдает круиз-контроль.

Дайте мне знать, если это поможет, или если у вас есть какие-либо вопросы.

Спасибо!

Answer 2

1) Сборка проекта с MSBUILD

2) FTP-файлы в производственную среду

3) Копирование / вставка вручную на каждый веб-сервер

Answer 3

Для сайтов интрасети мы используем CruiseControl в сочетании с SVN для автоматического восстановления сайта.

Теоретически вы могли бы расширить эту модель через VPN, если бы вы могли подключить диск удаленно к внутренней сети клиента. Или более быстрое и грязное решение может заключаться в использовании инструмента типа SyncBack для синхронизации удаленной папки, содержащей скомпилированные библиотеки DLL для сайта.

Answer 4

Мы используем проекты веб-развертывания и проекты VS 2008 для создания .msi из результатов веб-развертывания и других проектов. Обычное приложение для Windows, называемое «setup», используется для создания базы данных и предварительной подготовки, а не для настройки проектов установки с помощью пользовательских шагов. Гораздо проще сделать это самостоятельно, чем пытаться настроить код MS. Это приложение Windows затем вызывает правильные MSI-файлы, которые нужны пользователю.

Сборка Team Foundation выполняется каждый вечер, чтобы перестроить решение и скопировать все в каталог «Release CD», к которому любой может получить доступ и провести тестирование на последнем «релизе». Честно говоря, сборка TFS немного сложна для такой небольшой команды, как наша, и я использую ее только потому, что я к этому привык.

В предыдущей компании мы использовали это http://www.finalbuilder.com/, и я могу рекомендовать его для простоты использования и для количества поддерживаемого программного обеспечения.

Answer 5

Вот пара вещей, которые я сделал:

1) Использование проекта веб-развертывания для компиляции и очистки сборки, а также для замены раздела web.config в случае изменения конфигурации между средами. 2) Используйте NAnt для повторного построения, архивирования и копирования.

В результате проекта веб-развертывания создается файл MSBuild, который можно использовать вместо NAnt; тем не менее, я пришел из Java и все время использовал Ant, так что NAnt - мое предпочтение в .Net. Если вы добавите в задачи NAnt Contrib, вы сможете развертывать не только файлы, но и обрабатывать такие элементы, как управление исходным кодом (если оно не является частью задач по умолчанию) и выполнение сценария Sql для изменений.

В настоящее время я использую оба варианта вместе. У меня есть файл сборки NAnt для вызова проекта веб-развертывания через MSBuild. Благодаря настройке диспетчера конфигурации для каждой среды это позволяет мне автоматически управлять заменами раздела web.config и при этом иметь достаточно приличный контроль над моим копированием и архивированием выпуска.

Надеюсь, это поможет.

Answer 6

Развертывание веб-приложений с помощью Copy Web Tool
Текст из книги Microsoft Training Kit. Разработка через Интернет.
Проекты веб-настройки полезны, если вы предоставляете веб-приложение многим пользователям (например, позволяете пользователям загружать приложение из Интернета и устанавливать его). Если вы несете ответственность за обновление определенного веб-сайта для своей организации, нецелесообразно входить на веб-сервер и устанавливать пакет установщика Windows при каждом обновлении. Для внутренних приложений вы можете редактировать веб-приложение непосредственно на веб-сервере. Однако внесенные вами изменения сразу же внедряются в ваше производственное веб-приложение, и это включает в себя любые ошибки, которые могут там быть. Чтобы самостоятельно протестировать веб-приложение, вы можете отредактировать локальную копию веб-приложения на своем компьютере и опубликовать изменения на производственном веб-сервере с помощью инструмента «Копировать веб». Вы также можете использовать инструмент «Копировать веб» для публикации изменений с промежуточного сервера на рабочий веб-сервер или между любыми двумя веб-серверами. Инструмент «Копировать веб» может копировать отдельные файлы или весь веб-сайт на исходный веб-сайт и на удаленный веб-сайт или с него. Вы также можете выбрать синхронизацию файлов, которая включает в себя копирование только измененных файлов и обнаружение возможных конфликтов версий, когда один и тот же файл как на исходном, так и на удаленном сайте редактировался отдельно. Инструмент Copy Web не может объединять изменения в одном файле; можно копировать только полные файлы.