Как вы развертываете свои приложения ASP.NET на живых серверах? - PullRequest
102 голосов
/ 17 июля 2009

Я ищу различные методы / инструменты, которые вы используете для развертывания проекта веб-приложения ASP.NET ( НЕ веб-сайт ASP.NET) в рабочей среде?

Меня особенно интересует рабочий процесс, происходящий между моментом, когда ваш сервер Continuous Integration Build удаляет двоичные файлы в каком-то месте, и временем, когда первый пользовательский запрос достигает этих двоичных файлов.

  1. Вы используете какие-то специальные инструменты или просто XCOPY? Как упаковано приложение (ZIP, MSI, ...)?

  2. Когда приложение развертывается впервые, как вы настраиваете пул приложений и виртуальный каталог (вы создаете их вручную или с помощью какого-либо инструмента)?

  3. Когда статический ресурс изменяется (CSS, JS или файл изображения), вы повторно развертываете все приложение или только модифицированный ресурс? Как насчет изменения страницы сборки / ASPX?

  4. Отслеживаете ли вы все развернутые версии для данного приложения, и если что-то идет не так, есть ли у вас процедуры восстановления приложения до предыдущего известного рабочего состояния?

Не стесняйтесь дополнять предыдущий список.


И вот что мы используем для развертывания наших приложений ASP.NET:

  1. Мы добавляем Web Deployment Project к решению и настраиваем его для создания веб-приложения ASP.NET
  2. Мы добавляем в решение проект установки ( NOT Web Setup Project) и настраиваем его на получение выходных данных проекта веб-развертывания
  3. Мы добавляем пользовательское действие установки и в событии OnInstall запускаем пользовательскую сборку .NET, которая создает пул приложений и виртуальный каталог в IIS, используя System.DirectoryServices.DirectoryEntry (Эта задача выполнена только при первом развертывании приложения). Мы поддерживаем несколько веб-сайтов в IIS, аутентификацию для виртуальных каталогов и установку идентификаторов для пулов приложений.
  4. Мы добавляем пользовательскую задачу в TFS для создания проекта установки (TFS не поддерживает проекты установки, поэтому нам пришлось использовать devenv.exe для сборки MSI)
  5. MSI установлен на работающем сервере (при наличии предыдущей версии MSI он сначала удаляется)

Ответы [ 13 ]

2 голосов
/ 17 июля 2009

Еще в 2009 году, откуда пришел этот ответ, мы использовали CruiseControl.net для наших сборок Continuous Integration, которые также выводили Release Media.

Оттуда мы использовали программное обеспечение Smart Sync для сравнения с рабочим сервером, который не входил в пул с балансировкой нагрузки, и перенесли изменения вверх.

Наконец, после проверки версии, мы запустили сценарий DOS, который в основном использовал RoboCopy для синхронизации кода с работающими серверами, останавливая / запуская IIS по ходу работы.

1 голос
/ 30 апреля 2015

Я бы рекомендовал НЕ просто перезаписывать существующие файлы приложения, а вместо этого создавать каталог для каждой версии и переназначать приложение IIS на новый путь. Это имеет несколько преимуществ:

  • Быстрый возврат при необходимости
  • Нет необходимости останавливать IIS или пул приложений, чтобы избежать проблем с блокировкой
  • Нет риска старых файлов, вызывающих проблемы
  • Более или менее нулевое время простоя (обычно просто пауза при инициализации нового домена приложения)

Единственная проблема, с которой мы столкнулись, - это кэширование ресурсов, если вы не перезапускаете пул приложений и не используете автоматический переключатель приложений.

1 голос
/ 21 июня 2013

В последней компании, в которой я работал, мы использовали для развертывания пакетный файл rSync, чтобы выгрузить только изменения с момента последней загрузки. Прелесть rSync в том, что вы можете добавлять списки исключений для исключения определенных файлов или шаблонов имен файлов. Так что исключить все наши файлы .cs, файлы решений и проектов очень легко, например.

Мы использовали TortoiseSVN для контроля версий, и поэтому было приятно иметь возможность писать в нескольких командах SVN для выполнения следующего:

  • Прежде всего, убедитесь, что у пользователя установлена ​​последняя версия. Если нет, попросите их обновить или сразу же запустите обновление.
  • Загрузите текстовый файл с сервера «synclog.txt», в котором подробно описано, кем является пользователь SVN, какой номер редакции он загружает, а также дату и время загрузки. Добавьте новую строку для текущей загрузки, а затем отправьте ее обратно на сервер вместе с измененными файлами. Это позволяет очень легко определить, к какой версии сайта нужно вернуться, если существует вероятность, что загрузка вызовет проблемы.

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

И, наконец, rSync позволяет сделать резервную копию файлов, которые были заменены во время загрузки. Мы перенесли их в папку для резервных копий. Поэтому, если вы вдруг поняли, что некоторые файлы не должны были быть перезаписаны, вы можете найти последнюю версию резервной копии каждого файла в этой папке.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...