Як розгорнути веб-додаток .NET? (Рекомендації, будь ласка!)

Нещодавно ми оновили наш веб-сайт ASP.NET до веб-програми, і нас шокує раптовий стрибок у скруті при його розгортанні. Розглядаючи, наскільки це завдання має бути поширеним, мені було цікаво, які плагіни / програмне забезпечення використовують люди для розгортання проекту, що швидко розвивається, віддалено зберігається (наприклад, веб-сайт)?

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

Існує так багато вигадливих винятків файлів, що я повинен скоріше автоматизувати процес, щоб запобігти випадковому завантаженню.

За допомогою нашого старого рішення (на нашому веб-сайті) ми використовували Dispatch для 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, який виконує збірку. IMHO, простіший для читання та налагодження, ніж 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 я використовував тканину (fabfile.org) та capistrano (capify.org), які є інструментами автоматизації для надання віддалених команд SSH та SCP. Якщо на ваших хостах Windows встановлено Cygwin, ви повинні мати можливість використовувати їх повторно як інструменти розгортання.

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

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

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

Сказавши все, що поєднання інструменту веб-розгортання Microsoft з маршрутизацією запитів додатків - це один хороший варіант. У IIS7 можна створити інсталяційні пакети за допомогою інструменту. Також можна вказати інструмент на веб-додаток і створити резервну копію всього додатка в папці архіву додатків. Потім можна розгорнути з цієї папки архіву на IIS6 або веб-сервер IIS7 (IIS5 не підтримується). Я б використовував маршрутизацію запитів додатків, як Скотт запропонував відокремити реальні від тестових веб-сайтів. Після того, як ви перевірили, що нещодавно опублікований веб-сайт хороший, ви можете встановити ARR для переходу до нової версії.

PyroBatchFTP відмінно підходить для цього. Це натисне просто зміни, і ви можете їх зафіксувати так, що ви можете натиснути подвійним клацанням пакетного файлу.

У Vaasnet ми створили для себе рішення мрії, але воно досить задіяне в налаштуванні, але варто використовувати деякі або всі ці елементи, якщо можете. Ось що це:

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

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

Інший спосіб, про який не було запропоновано, я посилаю вас на «Gu» та проекти веб-налаштування

Це в основному створює інсталятор MSI для вашої програми .NET. Цей приклад стосується VS2005, але у мене є VS2010, і тип проекту все ще є. Це може дати вам багато налаштувань, якщо вам це потрібно, або просто основну установку, якщо цього не потрібно.

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

Існує маса способів зняти цю кішку, насправді залежить від того, який доступ ви можете мати на своєму сервері. Мій особистий улюблений метод запізнення - це встановити сценарій збірки в рамках проекту (як правило, використовуючи MSBUILD), який пакує всі файли розгортання, а потім використовувати SVN для переходу цих у виробництво. І до версії виробничих файлів.

База даних, найкраще, це використовувати якусь міграційну структуру. Знову ж таки, купа тих, хто біжить, і жодної реальної чіткої відповіді немає.

Особисто я просто використовую сценарій vbs, який я написав, щоб скопіювати папки певних файлів на сервер розробників (тобто залишити файли cs тощо).

Коли я працював у великій компанії .com, саме це ми робили з нашими розширеннями .net.

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

У день розгортання проекту ми використовуватимемо сценарій nAnt, щоб витягувати проекти з SVN, робити власну збірку проектів та витягувати будь-які залежності, необхідні цим проектам. Після запуску сценарію nAnt він був упакований у саморозпаковується поштовий файл. Збережені програми, пов’язані з цим розгортанням, перевірялися у вихідному елементі управління, а розширений аркуш Excel було оновлено зі сценаріями для запуску та в якому порядку.

Коли розгорнута мережа розімкнулася, саморозпаковується zip-файл передається на сервер, де він був запущений. Усі файли були вилучені у правильні каталоги, а DBA запустив збережені програми в базу даних продукувань.

За типового розгортання за допомогою цієї системи ми перейшли від п'яти до шести годин розгортання до менше години.

Удачі та сподівання, що це допоможе деяким у розробці способу розгортання вашої програми.

Має бути кращий спосіб, ніж просто "Публікація" у Visual Studio, а потім доведеться вручну FTP змінювати файли, які змінилися?

Бритва Оккама, як правило, є кращим підходом: чим простіше, тим краще. FTP легкий, без особливих ускладнень. Деякі люди використовують XCOPY, Filezilla або WSFTP, інші можуть використовувати інструмент розгортання веб-служб MS (який я ще не знайомий), але все-таки, є кращий спосіб розгортання веб-додатків ASP.NET (та інші додатки взагалі). IMO, якщо розгортання враховується з початку розробки, розгортання може бути інтегровано з веб-додатком, що надає відносно безболісне і плавне розгортання в майбутньому.

Як розробник .NET, який працював у кількох компаніях, що розробляють веб-додатки ASP.NET, розмірами, розмірами, складністю та кількістю користувачів (від декількох сотень користувачів до десятків тисяч), «розгортання» ІМО часто є найбільш «текучою» темою. Деякі організації сприймають це занадто далеко з точки зору бюрократії, тоді як інші взагалі не вирішують жодних проблем із розгортанням. На мій досвід, проблеми з розгортанням, як правило, підпадають під 1 або більше з 3-х категорій з точки зору труднощів / збоїв:

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

2. Розгортання складне для різних систем та людей, які грають: Складність - це сука. З MSMQ, T-SQL зберігаються процедури та тригери, Служби звітності, 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, з часом розробили певні стратегії роботи (принаймні) надійно.