Как вы развертываете свои приложения ASP.NET на живых серверах?

Question

Я ищу различные методы / инструменты, которые вы используете для развертывания проекта веб-приложения 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 он сначала удаляется)

Answer 1

У нас весь наш код развернут в MSI с использованием Setup Factory. Если что-то должно измениться, мы повторно развернем все решение. Это звучит как перебор для файла CSS, но он абсолютно синхронизирует все среды, и мы точно знаем, что находится в работе (мы развертываем во всех средах тестирования и uat одинаково).

Answer 2

Мы выполняем развертывание на действующих серверах, поэтому мы не используем проекты установщиков; у нас есть что-то похожее на CI:

• "живые" сборки сервера сборки из утвержденного источника (не "HEAD" репо)
• (после создания резервной копии ;-p)
• robocopy публикует на промежуточном сервере («вживую», но не в кластере F5)
• окончательная проверка, выполненная на промежуточном сервере, часто с использованием хаков «hosts» для эмуляции всего объекта как можно более точного
• robocopy / L используется автоматически, чтобы распространять список изменений в следующем «толчке», чтобы предупредить о любых глупостях
• как часть запланированного процесса, кластер циклически развертывается на узлах в кластере с помощью робокопии (пока они находятся вне кластера)

robocopy автоматически обеспечивает развертывание только изменений.

Re Пул приложений и т. Д .; Я бы полюбил это было бы автоматизировано ( см. Этот вопрос ), но в момент это ручное управление. Я действительно хочу это изменить.

(вероятно, помогает, что у нас есть собственный дата-центр и серверная ферма "на месте", поэтому нам не нужно преодолевать много препятствий)

Answer 3

Сайт

Deployer: http://www.codeproject.com/KB/install/deployer.aspx

Я публикую веб-сайт в локальную папку, архивирую его, затем загружаю по FTP. Затем Deployer на сервере извлекает zip, заменяет значения конфигурации (в Web.Config и других файлах), и все.

Конечно, для первого запуска вам необходимо подключиться к серверу и настроить IIS WebSite, базу данных, но после этого публикация обновлений становится легкой задачей.

База данных

Для синхронизации баз данных я использую http://www.red -gate.com / products / sql-development / sql-compare /

Если сервер находится за группой маршрутизаторов и вы не можете напрямую подключиться (что является требованием SQL Compare), используйте https://secure.logmein.com/products/hamachi2/ для создания VPN.

Answer 4

Я развертываю в основном приложения ASP.NET на серверах Linux и переворачиваю все, даже для самых маленьких изменений Вот мой стандартный рабочий процесс:

• Я использую репозиторий исходного кода (например, Subversion)
• На сервере у меня есть скрипт bash, который выполняет следующее:
  • Проверяет последний код
  • Выполняет сборку (создает библиотеки DLL)
  • Фильтрует файлы до самого необходимого (например, удаляет файлы кода)
  • Резервное копирование базы данных
  • Развертывает файлы на веб-сервере в каталоге с текущей датой
  • Обновляет базу данных, если в развертывание включена новая схема
  • Делает новую установку по умолчанию, поэтому она будет обслуживаться со следующим попаданием

Оформление заказа производится с помощью версии Subversion для командной строки, а сборка - с помощью xbuild (msbuild аналогично проекту Mono). Большая часть магии делается в ReleaseIt.

На моем dev-сервере у меня, по сути, непрерывная интеграция, но на производственной стороне я фактически подключаю SSH к серверу и запускаю развертывание вручную, запустив скрипт. Мой сценарий хитро называется 'deploy', поэтому я набираю его в командной строке bash. Я очень креативный. Не.

В производственном процессе мне приходится дважды вводить 'deploy': один раз для извлечения, сборки и развертывания в устаревшем каталоге, и один раз, чтобы сделать этот каталог экземпляром по умолчанию. Поскольку каталоги датированы, я могу вернуться к любому предыдущему развертыванию, просто набрав «deploy» из соответствующего каталога.

Первоначальное развертывание занимает пару минут, а возврат к предыдущей версии занимает несколько секунд.

Это было хорошее решение для меня, и оно опирается только на три утилиты командной строки (svn, xbuild и releaseit), клиент БД, SSH и Bash.

Мне действительно нужно когда-нибудь обновить копию ReleaseIt на CodePlex:

http://releaseit.codeplex.com/

Answer 5

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

Как разработчик для BuildMaster , это, естественно, то, что я использую. Все приложения создаются и упаковываются в инструмент как артефакты, которые хранятся внутри в виде ZIP-файлов.

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

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

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

По умолчанию процесс развертывания артефактов настроен таким образом, что на целевой сервер передаются только измененные файлы - это включает в себя все, от файлов CSS, файлов JavaScript, страниц ASPX и связанных сборок.

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

Да, BuildMaster обрабатывает все это для нас. Восстановление в основном так же просто, как и повторное выполнение старой сборки, но иногда изменения базы данных необходимо восстанавливать вручную, и может произойти потеря данных. Базовый процесс отката подробно описан здесь: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

Answer 6

Отвечая на ваши вопросы:

1. XCopy
2. вручную
3. Для статических ресурсов мы развертываем только измененный ресурс.
   Для DLL мы развернем измененные страницы DLL и ASPX.
4. Да и да.

Простота и удобство избавили нас от многих головных болей.

Answer 7

Простая XCopy для ASP.NET. Заархивируйте его, sftp на сервер, распакуйте в нужное место. Для первого развертывания, ручная настройка IIS

Answer 8

За прошедший год мы улучшали процесс выпуска, и теперь у нас его нет. Я использую Jenkins для управления всеми нашими автоматизированными сборками и выпусками, но я уверен, что вы можете использовать TeamCity или CruiseControl.

Таким образом, при регистрации наша "нормальная" сборка делает следующее:

• Дженкинс обновляет SVN, чтобы получить последнюю версию кода
• Восстановление пакета NuGet выполняется с использованием нашего собственного локального репозитория NuGet
• Приложение скомпилировано с использованием MsBuild. Настроить это - приключение, потому что вам нужно установить правильную MsBuild, а затем DLL-библиотеки ASP.NET и MVC в вашей сборочной коробке. (В качестве примечания: когда в мои файлы .csproj были введены <MvcBuildViews>true</MvcBuildViews> для компиляции представлений, msbuild случайно зависал, поэтому мне пришлось отключить его)
• Как только код скомпилирован, запускаются модульные тесты (для этого я использую nunit, но вы можете использовать все, что захотите)
• Если все модульные тесты пройдены, я останавливаю пул приложений IIS, развертываю приложение локально (всего несколько основных команд XCOPY для копирования необходимых файлов), а затем перезапускаю IIS (у меня были проблемы с файлами блокировки IIS, и это решило это)
• У меня есть отдельные файлы web.config для каждой среды; dev, uat, prod. (Я пытался использовать веб-трансформацию без особого успеха). Таким образом, правильный файл web.config также копируется в
• Затем я использую PhantomJS для выполнения нескольких тестов пользовательского интерфейса. Он также делает несколько скриншотов с различным разрешением (мобильное, настольное) и маркирует каждый скриншот некоторой информацией (заголовок страницы, разрешение). Jenkins прекрасно поддерживает обработку этих скриншотов, и они сохраняются как часть сборки
• После прохождения тестов интерфейса интеграции сборка прошла успешно

Если кто-то нажимает «Развернуть в UAT»:

• Если последняя сборка прошла успешно, Дженкинс делает еще одно обновление SVN
• Приложение скомпилировано с использованием конфигурации RELEASE
• Каталог "www" создан и приложение скопировано в него
• Затем я использую winscp для синхронизации файловой системы между блоком сборки и UAT
• Я отправляю HTTP-запрос на сервер UAT и проверяю, вернул ли я 200
• Эта редакция помечена в SVN как UAT-datetime
• Если мы дошли до этого, сборка прошла успешно!

Когда мы нажимаем «Deploy to Prod»:

• Пользователь выбирает ранее созданный тег UAT
• Метка "переключена" на
• Код компилируется и синхронизируется с сервером Prod
• HTTP-запрос к серверу Prod
• Эта редакция помечена в SVN как Prod-datetime
• Релиз архивируется и хранится

Вся полная сборка до производства занимает около 30 секунд, и я очень, очень доволен.

Вверх к этому решению:

• Это быстро
• Модульные тесты должны отлавливать логические ошибки
• Когда ошибка пользовательского интерфейса будет запущена в производство, на скриншотах будет показано, какая ревизия # вызвала ее
• UAT и Prod синхронизируются
• Jenkins показывает вам отличную историю релизов для UAT и Prod со всеми сообщениями фиксации
• Все версии UAT и Prod помечены автоматически
• Вы можете видеть, когда релизы происходят и кто их сделал

Основные недостатки этого решения:

• Всякий раз, когда вы делаете релиз для Prod, вы должны делать релиз для UAT. Это было сознательное решение, которое мы приняли, потому что мы всегда хотели убедиться, что UAT всегда в курсе Prod. Тем не менее, это боль.
• Существует довольно много файлов конфигурации. Я пытался получить все это в Дженкинсе, но есть несколько вспомогательных командных файлов, необходимых как часть процесса. (Они также проверены).
• Сценарии обновления и понижения БД являются частью приложения и запускаются при запуске приложения. Это работает (в основном), но это боль.

Я бы хотел услышать о любых других возможных улучшениях!

Answer 9

Развернуть - это решение для развертывания, подобное капистрано, которое я написал для приложений .net. Это то, что мы используем во всех наших проектах, и это очень гибкое решение. Он решает большинство типичных проблем для приложений .net, как объяснено в этом блоге Робом Конери.

• он поставляется с хорошим поведением по умолчанию, в том смысле, что он делает много стандартных вещей для вас: получение кода из системы контроля версий, сборка, создание пула приложений, настройка IIS и т. Д.
• релизы, основанные на управлении исходным кодом
• имеет перехватчиков задач , поэтому поведение по умолчанию может быть легко расширено или изменено
• имеет откат
• это все powershell , поэтому внешних зависимостей нет
• он использует удаленное взаимодействие PowerShell для доступа к удаленным машинам

Вот введение и некоторые другие сообщения в блоге.

Итак, чтобы ответить на вопросы выше:

• Как упаковано приложение (ZIP, MSI, ...)?

  Git (или другой scm) - это способ по умолчанию получить приложение на целевой машине. В качестве альтернативы вы можете выполнить локальную сборку и скопировать результат через удаленное соединение Powereshell

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

  Развернуть конфигурирует пул приложений и веб-приложение с помощью модуля веб-администрирования Powershell. Это позволяет нам (и вам) изменять любой аспект пула приложений или веб-сайта

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

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

• Отслеживаете ли вы все развернутые версии для данного приложения?

  Да, Unold сохраняет старые версии. Не все версии, но ряд версий. Это делает откат почти тривиальным.

Answer 10

веб-настройка / установка проектов - так что вы можете легко удалить его, если что-то пойдет не так