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

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

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

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

Мы развертываем развертывание на живых серверах, поэтому мы не используем проекты установщика; у нас есть нечто большее, чем CI:

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

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

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

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

Ответ 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.

Ответ 4

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

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

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

На моем dev-сервере у меня по существу есть непрерывная интеграция, но на стороне производства я на самом деле SSH на сервер и инициирую развертывание вручную, запустив script. Мой script искусно называется "развернуть" , так что я набираю текст в приглашении bash. Я очень креативен. Нет.

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

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

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

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

http://releaseit.codeplex.com/

Ответ 5

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

Ответ 6

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

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

Сохранение этого приятного и простого спасло нас от головных болей до сих пор.

Ответ 7

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

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

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

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

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

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

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

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

Ответ 8

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

Ответ 9

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

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

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

Итак, чтобы ответить на следующие вопросы:

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

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

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

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

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

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

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

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

Ответ 10

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

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

  • Jenkins делает обновление 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":

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

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

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

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

Переход на это решение:

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

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

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

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

Ответ 11

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

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

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

Ответ 12

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

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

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

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

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

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

Ответ 13

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

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

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