Як ви розгортаєте свої програми ASP.NET на живих серверах?

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

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

1. Ви використовуєте якісь конкретні інструменти або просто XCOPY? Як пакується додаток (ZIP, MSI, ...)?

2. Коли програма вперше розгорнута, як налаштувати пул додатків та віртуальний каталог (чи створюєте ви їх вручну чи за допомогою якогось інструмента)?

3. Коли статичний ресурс змінюється (CSS, JS або файл зображення), ви переукладаєте всю програму або лише модифікований ресурс? Як щодо того, коли сторінка збірки / ASPX змінюється?

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

Сміливо заповнюйте попередній список.

Ось що ми використовуємо для розгортання наших програм ASP.NET:

1. До рішення додаємо проект веб-розгортання та налаштовуємо його на створення веб-програми ASP.NET
2. Ми додаємо проект рішення ( НЕ проект веб-налаштування) до рішення та встановлюємо його для отримання результату проекту веб-розгортання.
3. Ми додаємо власну дію встановлення і в події OnInstall запускаємо власну збірку .NET збірки, яка створює пул додатків і віртуальний каталог в IIS за допомогою System.DirectoryServices.DirectoryEntry (Це завдання виконується лише при першому розгортанні програми) . Ми підтримуємо декілька веб-сайтів у IIS, автентифікацію віртуальних каталогів та встановлення ідентифікацій для пулів додатків.
4. Ми додаємо в TFS спеціальне завдання для створення проекту налаштування (TFS не підтримує проекти налаштування, тому нам довелося використовувати devenv.exe для створення MSI)
5. MSI встановлюється на реальному сервері (якщо є попередня версія MSI, її спочатку видаляють)

Весь наш код розгорнуто в MSI, використовуючи Setup Factory. Якщо щось має змінитися, ми перерозподіляємо все рішення. Це звучить як надмірний вміст для файлу css, але він абсолютно підтримує синхронізацію всіх середовищ, і ми точно знаємо, що є у виробництві (ми розгортаємо всі тестові та uat середовища однаково).

Ми робимо розгортання на живих серверах, тому не використовуємо проекти інсталятора; у нас є щось більше, як CI:

• "live" build-сервер будує з затвердженого джерела (а не "HEAD" репо)
• (після того, як він взяв резервну копію ;-p)
• Робокопія публікується на сервісі, що працює на етапі ("в прямому ефірі", але не в кластері F5)
• остаточна перевірка, виконана на сервері постановки, часто із хаками "господарів", щоб імітувати всю справу як можна ближче
• robocopy / L використовується автоматично для розповсюдження списку змін у наступному "натисканні", для оповіщення про будь-які відхилення
• як частина запланованого процесу, кластер циклізується, розгортаючись до вузлів кластера за допомогою роботоскопії (поки вони поза кластером)

робокопія автоматично забезпечує лише розгортання змін.

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

(це, мабуть, допомагає нам мати власний центр обробки даних і ферму серверів "на місці", тому нам не доведеться перетинати багато перешкод)

Веб-сайт

Розгортач: http://www.codeproject.com/KB/install/deployer.aspx

Я публікую веб-сайт у локальній папці, завантажую його в папку та завантажую через FTP. Потім розгортач на сервері витягує zip, замінює значення конфігурації (у Web.Config та інших файлах), і все.

Звичайно, для першого запуску вам потрібно підключитися до сервера та налаштувати базу даних IIS WebSite, але після цього публікація оновлень - це торт.

База даних

Для синхронізації баз даних я використовую http://www.red-gate.com/products/sql-development/sql-compare/

Якщо сервер стоїть за купою маршрутизаторів, і ви не можете безпосередньо підключитися (що є вимогою порівняння SQL), використовуйте https://secure.logmein.com/products/hamachi2/ для створення VPN.

Я розгортаю в основному додатки ASP.NET на серверах Linux і перерозподіляю все для навіть найменших змін. Ось мій стандартний робочий процес:

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

Оформлення замовлення виконується за допомогою версії Subversion у командному рядку, а побудова виконується за допомогою xbuild (msbuild work-like from Mono project). Більшість магії робиться в ReleaseIt.

На моєму сервері розробників я, по суті, безперервно інтегруюсь, але на виробничій стороні я фактично SSH в сервер і ініціюю розгортання вручну, запустивши скрипт. Мій сценарій спритно називається "розгортати", тому я набираю підказку bash. Я дуже креативний. Ні.

У виробництві я повинен два рази набрати 'розгортати': один раз, щоб перевірити, скласти та розгорнути у датованій папці та один раз, щоб зробити цей каталог екземпляром за замовчуванням. Оскільки каталоги датовані, я можу повернутися до будь-якого попереднього розгортання, просто ввівши «розгорнути» з відповідного каталогу.

Початкове розгортання займає пару хвилин, а перехід до попередньої версії займає кілька секунд.

Це було приємним рішенням для мене і покладається лише на три утиліти командного рядка (svn, xbuild та releaseit), клієнт DB, SSH та Bash.

Мені дійсно потрібно десь оновити копію ReleaseIt на CodePlex:

http://releaseit.codeplex.com/

Простий XCopy для ASP.NET. Застебніть його, переїдьте на сервер, витягніть в потрібне місце. Для першого розгортання, ручне налаштування IIS

Відповідаючи на ваші запитання:

1. XCopy
2. Вручну
3. Для статичних ресурсів ми розгортаємо лише змінений ресурс.
   Для DLL ми розгортаємо змінені сторінки DLL та ASPX.
4. Так, і так.

Тримаючи це приємно і просто, врятувало нас поки що багато головних болів.

Ви використовуєте якісь конкретні інструменти або просто XCOPY? Як пакується додаток (ZIP, MSI, ...)?

Як розробник для BuildMaster , це, звичайно, те, що я використовую. Усі програми створюються та упаковуються в межах інструменту як артефакти, які зберігаються всередині файлів ZIP.

Коли програма вперше розгорнута, як налаштувати пул додатків та віртуальний каталог (чи створюєте ви їх вручну чи за допомогою якогось інструмента)?

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

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

За замовчуванням процес розгортання артефактів налаштовується таким чином, що на цільовий сервер переносяться лише модифіковані файли - сюди входить все, починаючи з файлів CSS, файлів JavaScript, сторінок ASPX та пов'язаних збірок.

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

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

веб-налаштування / встановлення проектів - ви можете легко видалити його, якщо щось піде не так

Відкривається є Capistrano типу розгортання рішенняя написав для додатків .NET. Це те, що ми використовуємо у всіх наших проектах, і це дуже гнучке рішення. Він вирішує більшість типових проблем для .net-додатків, як це пояснив у цьому блозі Роб Конери.

• він має хорошу поведінку "за замовчуванням", в тому сенсі, що він робить для вас багато стандартних речей: отримання коду з управління джерелом, побудова, створення пулу додатків, налаштування IIS тощо
• випуски на основі того, що знаходиться в контролі джерела
• він має гачки завдань , тому поведінку за замовчуванням можна легко розширити або змінити
• він має відкат
• це все повноваження , тому немає ніяких зовнішніх залежностей
• він використовує видалення оболонки для доступу до віддалених машин

Ось вступ та деякі інші публікації в блозі.

Отже, щоб відповісти на запитання вище:

• Як пакується додаток (ZIP, MSI, ...)?

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

• Коли програма вперше розгорнута, як налаштувати пул додатків та віртуальний каталог (чи створюєте ви їх вручну чи за допомогою якогось інструмента)?

  Розгортання налаштовує пул додатків та додаток веб-сайтів за допомогою модуля веб-адміністрування Powershell. Це дозволяє нам (і ви) змінювати будь-який аспект пулу додатків або веб-сайту

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

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

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

  Так, розгортання зберігає старі версії навколо. Не всі версії, але ряд версій. Це робить відкат назад майже тривіальним.

Ми вдосконалювали процес випуску впродовж останнього року, і тепер ми його знищили. Я використовую 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, щоб виконати купу тестів на інтерфейс. Він також займає купу скріншотів з різною роздільною здатністю (для мобільних пристроїв, настільних ПК) і відбиває кожен знімок екрана деякою інформацією (назва сторінки, роздільна здатність). Дженкінс має чудову підтримку для обробки цих скріншотів, і вони зберігаються як частина збірки
• Як тільки тести інтеграційного інтерфейсу інтеграції пройдуть, збірка успішна

Якщо хтось натискає "Розгорнути в UAT":

• Якщо остання збірка була успішною, Дженкінс робить ще одне оновлення SVN
• Додаток компілюється за допомогою конфігурації RELEASE
• Створюється каталог "www", і додаток копіюється в нього
• Потім я використовую wincp для синхронізації файлової системи між полем збірки та UAT
• Я надсилаю запит HTTP на сервер UAT і переконуюсь, що я отримаю 200
• Ця редакція позначена в SVN як UAT-datetime
• Якщо у нас це далеко, побудова успішна!

Коли ми натискаємо "Розгорнути в програму":

• Користувач вибирає тег UAT, який був створений раніше
• Тег "перемикається" на
• Код складається і синхронізується з сервером Prod
• HTTP-запит на сервер Prod
• Ця редакція позначена в SVN як час додавання
• Випуск зіштовхується та зберігається

Повноцінне виробництво займає близько 30 секунд, якими я дуже, дуже задоволений.

Переваги цього рішення:

• Це швидко
• Одиничні тести повинні вловлювати логічні помилки
• Коли помилка у користувальницькому інтерфейсі потрапить у виробництво, скріншоти, сподіваємось, покажуть, яка редакція # викликала це
• UAT і Prod синхронізуються
• Дженкінс показує вам велику історію випусків UAT та Prod з усіма повідомленнями про фіксацію
• Випуски UAT і Prod всі позначаються автоматично
• Ви можете бачити, коли трапляються випуски та хто їх робив

Основні недоліки цього рішення:

• Щоразу, коли ви робите реліз Prod, вам потрібно робити випуск в UAT. Це було свідоме рішення, яке ми прийняли, оскільки хотіли завжди гарантувати, що UAT завжди буде в курсі Prod. Все-таки це біль.
• Навколо плаває досить багато файлів конфігурації. Я намагався мати все це в Дженкінсі, але є кілька пакетних файлів підтримки, необхідних у рамках процесу. (Вони також зареєстровані).
• Сценарії оновлення та поновлення БД є частиною програми та запускаються при запуску програми. Це працює (в основному), але це біль.

Я хотів би почути будь-які інші можливі вдосконалення!

Ще в 2009 році, звідки ця відповідь прозвучала, ми використовували CruiseControl.net для побудови безперервної інтеграції, яка також виводила засоби випуску.

Звідти ми використовували програмне забезпечення Smart Sync для порівняння з виробничим сервером, який був поза пулом збалансованого навантаження, і переміщували зміни вгору.

Нарешті, після перевірки випуску, ми застосували сценарій DOS, який в основному використовував RoboCopy для синхронізації коду з живими серверами, зупиняючи / запускаючи IIS по мірі проходження.

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

Ми використовували TortoiseSVN для контролю версій, і тому було приємно мати можливість записати кілька команд SVN, щоб виконати наступне:

• Спочатку перевірте, чи є у користувача остання версія. Якщо ні, то або запропонуйте їм оновити або запустити оновлення прямо там і потім.
• Завантажте текстовий файл із сервера під назвою "synclog.txt", в якому детально описується, хто саме користувач SVN, номер редакції, який вони завантажують, а також дата та час завантаження. Додайте новий рядок для поточного завантаження та відправте його назад на сервер разом із зміненими файлами. Це робить надзвичайно легко дізнатися, до якої версії веб-сайту можна повернутись із випадковою можливістю, що завантаження спричинить проблеми.

На додаток до цього є другий пакетний файл, який просто перевіряє наявність файлових відмінностей на живому сервері. Це може виділити загальну проблему, коли хтось завантажував, але не здійснював їх зміни у SVN. У поєднанні з журналом синхронізації, згаданим вище, ми могли з'ясувати, хто ймовірний винуватець, і попросити їх виконати свою роботу.

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

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

Я рекомендую НЕ просто перезаписувати наявні файли додатків, а натомість створити каталог за версією та перенаправити програму IIS на новий шлях. Це має ряд переваг:

• Швидке відновлення, якщо потрібно
• Не потрібно зупиняти IIS або пул додатків, щоб уникнути проблем із блокуванням
• Немає ризику виникнення проблем із старими файлами
• Більш-менш нульовий час простою (зазвичай це просто пауза в новому додатку ініціалізується)

Єдине питання, яке ми мали, це кешування ресурсів, якщо ви не перезапускаєте пул додатків і не покладаєтесь на автоматичний перемикач додатків домену.