Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

В качестве другого способа, который не предлагался, я отсылаю вас к «Гу» и Проекты веб-настройки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  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, имеют со временем выработанные определенные стратегии работают (как минимум) надежно.