Как вы развертываете свое .NET веб-приложение? (Рекомендации, пожалуйста!)

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

Должен быть лучший способ, чем просто «Публикация» в Visual Studio и необходимость вручную передавать файлы FTP, которые были изменены? Не в последнюю очередь потому, что сайт закрывается, когда мы загружаем наши .DLL.

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

С нашим старым решением (на нашем веб-сайте) мы использовали Dispatch for ASP, который полностью закачался и сделал весь процесс одним щелчком мыши. К сожалению, это не очень хорошо для DLL (как упоминалось ранее).

Так как ваша команда это делает?

Спасибо за любой совет.

PS - Я читал, что Visual Studio 2010 должен устранить эти недостатки в VS2005 / 08, но до тех пор ...

Я настоятельно рекомендую использовать непрерывную интеграцию.

Мы используем комбинацию TeamCity для CI, Rake и Albacore для автоматизации сборки.

TeamCity проверит код из вашего репозитория исходного кода, затем, используя Rake, соберет приложение, выполнит модульные тесты и даже запустит ваши скрипты базы данных, если вы того пожелаете. После успешной сборки вы можете упаковать ваш исходный код в zip-файл или скопировать его в место назначения по вашему выбору.

Мы используем Git, хотя TeamCity работает со всеми системами контроля версий.

Использование TeamCity и Rake будет похоже на использование CruiseControl и NANT без редактирования файла XML. Конечно, вы можете использовать TeamCity с NANT, если хотите.

Короткий пример взят из rakefile.rb, который выполняет сборку. ИМХО, легче читать и отлаживать, чем файл XML.

require 'albacore'
require 'rexml/document'
require 'find'

VERSION_NO = "1.0"

OUTPUT_PATH = "output"
WEBOUTPUT_PATH = "output/web"
ADMINOUTPUT_PATH = "output/admin"

CONFIG = "Release"

WEB_PATH = "app/Company.Website.Web"
ADMIN_PATH = "app/Company.Website.Admin"
PACKAGE_PATH = "build/package"
DB_SCRIPT_PATH = "Company.Website.DB"
SOLUTION = "Company.Website.sln"

ARTIFACTS_PATH = "d:/build/artifacts/"

DEPLOY_WEB_PATH = "d:/deploy/company/website/"
DEPLOY_ADMIN_PATH = "d:/deploy/company/admin/"

task :default => ['setuptest','assemblyinfo','config','msbuild','createdb','sqlcmd','deploy']


task :setuptest do |setup|
  if ENV['BuildNumber'].nil? then ENV['BuildNumber'] = "000" end

  VERSION_NO = VERSION_NO + '.' + ENV['BuildNumber']
  puts 'Version Number : ' + VERSION_NO

  ZIPFILE_WEB = 'Company.Website.Web.' + VERSION_NO
  ZIPFILE_ADMIN = 'Company.Website.Admin.' + VERSION_NO  

  DB_SERVER = "WEB2"
  DB_DATABASE = "Website"  
  CREATEDB_SCRIPT = "app/Company.Website.DB/00CreateDatabaseTEST.sql"
end

  assemblyinfotask do |asm|
    asm.version = VERSION_NO
    asm.company_name = "Company Name"
    asm.copyright = "Copyright 2010"
    asm.output_file = "CommonAssemblyInfo.cs"
  end

  task :config do
    FileUtils.cp 'NHibernate.test.config', 'NHibernate.config'
  end

  msbuildtask do |msb|
    msb.properties = { :configuration => :Debug }
    msb.targets [:Clean, :Build]
    msb.solution = "Company.Website.sln"
  end

  sqlcmdtask :createdb do |sql|
    puts "executing sql scripts..."
    sql.log_level = :verbose
    sql.path_to_command = "sqlcmd.exe"
    sql.server = DB_SERVER
    sql.database = "master"
    sql.scripts << CREATEDB_SCRIPT
  end

  sqlcmdtask do |sql|
    puts "executing sql scripts..."
    sql.log_level = :verbose
    sql.path_to_command = "sqlcmd.exe"
    sql.server = DB_SERVER
    sql.database = DB_DATABASE
    sql.scripts << "app/Company.Website.DB/01CreateTables.sql"
    sql.scripts << "app/Company.Website.DB/02InsertReferenceData.sql"
  end

  task :deployprep do

    FileUtils.remove_dir 'app/Company.Website.Web/obj'
    FileUtils.remove_dir 'app/Company.Website.Admin/obj'

  end

  ziptask :zipweb do |zip|
    puts "creating zip package in " + ZIPFILE_WEB
    zip.directories_to_zip = ["app/Company.Website.Web"]
    zip.output_file = ZIPFILE_WEB  + '.zip'
    zip.output_path = File.dirname(__FILE__)
  end

  ziptask :zipadmin do |zip|
      puts "creating zip package in " + ZIPFILE_ADMIN
    zip.directories_to_zip = ["app/Company.Website.Admin"]
    zip.output_file = ZIPFILE_ADMIN  + '.zip'
    zip.output_path = File.dirname(__FILE__)
  end  

Albacore - это набор задач Rake, специально созданный для развертывания приложения .NET.

В Linux я использовал fabric (fabfile.org) и capistrano (capify.org), которые являются инструментами автоматизации для помощи в удаленных командах SSH и SCP. Если на хостах Windows установлен Cygwin, вы сможете использовать их в качестве инструментов развертывания.

«Публикация» веб-приложения в Visual Studio может быть запущена из командной строки как msbuild "C:\proj\yourprojectpathandfilename.csproj" /deploydir:"C:\some\deploy\dir". Каталог назначения - это развертываемое веб-приложение.

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

Я согласен со Скоттом, что это может быть очень сложно и легко упускать из виду. Стратегия развертывания также зависит от конкретного приложения. Если ваше приложение полностью содержится в одной папке, это может быть проще, чем приложение, которое ссылается на GAC. Что, в свою очередь, может быть проще, чем сервер, которому необходимо поддерживать несколько версий приложения, которое ссылается на несколько версий сборок GAC. Мы не хотим начинать говорить о файлах политики здесь :).

Сказав все это, объединение Microsoft Web Deployment Tool с маршрутизацией запросов приложений - один из хороших вариантов. В IIS7 можно создавать установочные пакеты с помощью инструмента. Также возможно указать инструмент на веб-приложение и сделать резервную копию всего приложения в папке архива приложения. Затем можно выполнить развертывание из этой архивной папки на веб-сервер IIS6 или IIS7 (IIS5 не поддерживается). Я бы использовал маршрутизацию запросов приложений, как предложил Скотт, для отделения живых сайтов от тестовых. Убедившись, что недавно опубликованный веб-сайт исправен, вы можете настроить ARR для перехода к новой версии.

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

В Vaasnet мы настроили решение мечты для себя, но оно довольно сложно для настройки, но стоит использовать некоторые или все эти элементы, если вы можете. Вот что это:

• SVN на всех наших разработках
• SVN на нашем сервере сборки / развертывания
• Cruisecontrol.net отслеживает изменения в SVN и собирает и помещает только необходимые файлы в промежуточную папку
• используя PyroBatchFTP, мы перемещаемся на промежуточный сайт (запускается Cruisecontrol, поэтому это происходит автоматически)
• используя IIS7 и маршрутизацию запросов приложений (ARR) и URL Rewrite, мы имеем следующую промежуточную / производственную настройку:
  • ARR сразу направит трафик либо к экземпляру 01, либо к 02, в зависимости от того, какой из них «живой», а какой «промежуточный»
  • учетная запись FTP всегда связана с «подготовкой»
  • У меня есть другой мини-админ-сайт, который поменяет местами постановку и будет жить одним кликом. Чтобы переключиться с нулевым временем простоя, требуется всего 1 секунда, и мы можем переключиться обратно, если поймем, что с этим выпуском что-то не так (хотя это редко, так как мы можем так легко это проверить перед запуском в эксплуатацию).

Таким образом, чистый результат позволяет нам регистрироваться в SVN и автоматически его создавать и отправлять в производство без какого-либо ручного взаимодействия. После того, как мы проверили наш промежуточный URL и определили, что он готов к работе, мы заходим на простой сайт и одним нажатием он становится активным.

Для другого способа, который не был предложен, я отсылаю вас к проектам Gu и Web Setup.

Это в основном создает установщик MSI для вашего приложения .NET. Этот пример для VS2005, но у меня есть VS2010, и тип проекта все еще там. Это может дать вам много настроек, если вам это нужно, или просто базовую установку, если вам это не нужно.

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

Есть много способов обшарить эту кошку, на самом деле все зависит от того, сколько у вас есть доступа к вашему серверу. Мой личный любимый метод в последнее время - это установка сценария сборки в проекте (обычно с использованием MSBUILD), который упаковывает все файлы развертывания, а затем использует SVN для их подключения к работе. И для версии производственных файлов.

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

Лично я просто использую сценарий VBS, который я написал сам, чтобы скопировать папки определенных типов файлов на сервер разработки (то есть пропустить файлы CS и т. Д.).

Когда я работал в крупной компании .com, это то, что мы делали с нашими развертываниями .net.

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

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

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

В типичном развертывании с использованием этой системы мы перешли от пяти до шести часов развертывания к менее чем часу или меньше.

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

Должен быть лучший способ, чем просто «Публикация» в Visual Studio и необходимость вручную передавать файлы FTP, которые были изменены?

Бритва Оккама обычно является предпочтительным подходом: чем проще, тем лучше. FTP легко с небольшими или без осложнений. Некоторые люди используют XCOPY, Filezilla или WSFTP, другие могут использовать MS Web Deployment Tool (с которым я еще не знаком), но в целом есть лучший способ развертывания веб-приложений ASP.NET (и других приложения в общем). ИМО, если развертывание учитывается с самого начала разработки, развертывание можно интегрировать с веб-приложением, что обеспечивает относительно безболезненное и плавное развертывание в будущем.

Будучи разработчиком .NET, который работал в нескольких компаниях, разрабатывающих веб-приложения ASP.NET разных размеров, сложности и количества пользователей (от нескольких сотен пользователей до десятков тысяч), «развертывание» IMO часто является наиболее «плавной» темой. Некоторые организации слишком далеко зашли с точки зрения бюрократии, в то время как другие вообще не решают никаких проблем с развертыванием. По моему опыту, проблемы с развертыванием имеют тенденцию делиться на 1 или более из 3 категорий с точки зрения трудностей / неудач:

1. Развертывание игнорируется / забывается подробно на этапе проектирования: большинство веб-приложений, как правило, включают веб-сервер и базу данных. Помимо кода приложения, может быть, некоторых хранимых процедур и таблиц базы данных, развертывание не требует особых размышлений. ASP.NET более чем способна помочь в развертывании, но чаще всего разработчики отвлекаются с точки зрения запуска реального приложения и выполнения его задачи, оставляя способ развертывания как отдельную проблему.

2. Развертывание является сложным в нескольких системах и в игре людей: сложность это сука. От MSMQ, хранимых процедур и триггеров T-SQL, служб Reporting Services, обмена сообщениями SOAP / XML, аутентификации AD, SSAS / SSIS и т. Д. И т. Д. Количество используемых технологий увеличивает количество вовлеченных людей. Хуже всего то, что все эти разные компоненты, как правило, управляются разными объектами внутри организации. Если все не синхронизируются друг с другом, развертывание может усложниться быстро, что приведет к множеству точек отказа.

3. Лень, апатия или отсутствие общения и / или управления: от небольшого количества документов до отсутствия или отсутствия скоординированного общения и протоколов, можно легко запутать относительно простой процесс. Развертывание должно быть простой процедурой с многочисленными проверками, постоянно документирующими то, что сделано, но часто это не так. Большинство людей просто хотят, чтобы этот чертов сайт заработал. По моему опыту, людям (не программистам) все равно, пока что-то не пойдет по- настоящему . Ответственность за развертывание редко ложится на одного человека , поскольку никто не хочет быть причиной неудачи, поэтому ответственность обычно рассеивается.

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

Я не знаю ни одного поставщика для автоматизации развертывания, хотя я бы не удивился, если бы их было несколько. Возможно, вы могли бы написать сценарий решения через VBScript / WMI или пакетный сценарий решения, но реальность такова, что вам нужно адаптировать решение вместе для более сложных сайтов ASP.NET. Простые сайты, состоящие из страниц, подключения к базе данных и ничего более, вам не нужно делать почти столько же, так что масштабируйте свои усилия по развертыванию в соответствии со сложностью самого приложения.

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

• Ничего не предполагать Учетные записи пользователей, права R / W / X, списки ACL, брандмауэры, время (когда развертывать и сколько времени у вас есть на это), и, если возможно, тестировать развертывание во всех средах до окончательной «даты запуска».
• Прежде чем начнется разработка, необходимо внедрить фактор в разработку. Если это простой сайт, пусть будет так. Если имеется множество движущихся частей, учтите все это и фактически создайте план, в котором все компоненты (код, база данных, отчеты, очереди и т. Д.) Находятся в одном плане.
• Координировать с другими паритетами и общаться эффективно и действенно.
• Документируйте как можно больше соответствующей информации, если это возможно.
• Среда: один веб-сервер против веб-фермы; 32-разрядный или 64-разрядный; найти способ мониторинга логов / ошибок / поворота и т. д.
• Найдите (или создайте) инструменты, которые могут помочь в развертывании.
• Если возможно для программируемого развертывания, выберите парадигму и придерживайтесь ее. Например, если вы хотите использовать сервер базы данных в качестве основного средства для выполнения состояния приложения, развертывания, доступа и т. Д., Запустите его в приложение и придерживайтесь его. Если вы предпочитаете читать файлы XML (например, web.config) всеми средствами, просто придерживайтесь последовательной парадигмы развертывания приложения. Другой пример: некоторые организации оставляют файл web.config в виде статического файла в каждой среде, который не следует развертывать в других средах. Другая программа web.config таким образом, что она может быть развернута в разных средах без ошибок.

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