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

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

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

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

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

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

Сайт

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.

Я развертываю в основном приложения 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/

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

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

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

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

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

Мы улучшаем процесс выпуска в течение прошедшего года, и теперь у нас это получилось. Я использую 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. Тем не менее, это боль.
• Там довольно много файлов конфигурации. Я попытался сделать все это в Дженкинсе, но там есть несколько вспомогательных пакетных файлов, которые необходимы как часть процесса. (Они также проверяются).
• Сценарии обновления и понижения БД являются частью приложения и запускаются при запуске приложения. Он работает (в основном), но это боль.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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