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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интернет сайт

Разработчик: 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.

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

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

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

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

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

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

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

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

http://releaseit.codeplex.com/

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

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

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

Сохранение простоты и простоты пока избавило нас от множества головных болей.

Вы используете какие-то специальные инструменты или просто 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Дженкинс выполняет обновление SVN, чтобы получить последнюю версию кода.
• Восстановление пакета NuGet выполняется в нашем собственном локальном репозитории NuGet.
• Приложение скомпилировано с использованием MsBuild. Настроить это - приключение, потому что вам нужно установить правильный MsBuild, а затем библиотеки DLL ASP.NET и MVC в поле сборки. (В качестве побочного примечания, когда я <MvcBuildViews>true</MvcBuildViews>ввел свои файлы .csproj для компиляции представлений, 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
• Если мы зашли так далеко, сборка прошла успешно!

Когда мы нажимаем «Развернуть на Prod»:

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

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

Плюсы этого решения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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