Какой метод вы используете для развертывания приложений ASP.Net в дикой природе?

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

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

Во-вторых, я смотрю на объединение развертываний и автоматических обновлений.

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


deployment asp.net wix
person Hooloovoo    schedule 10.06.2009    source источник
comment
Поскольку я опубликовал этот исходный вопрос, я открыл для себя WiX. Это открытый исходный код и бесплатный. Это также то, что Microsoft использовала для разработки пакета развертывания для Office 2007. Он кажется простым в использовании, если вы понимаете основы, а интерфейс позволяет вам выбирать компоненты во время установки.   -  person Hooloovoo    schedule 03.12.2009
comment
Просто обновление; Инструмент автоматизации выпуска приложений разработан специально для этой цели. Существует множество замечательных инструментов, которые можно сравнить с ru .wikipedia.org / wiki / Application_release_automation   -  person Karl Harnagy    schedule 27.06.2016

Ответы (6)


arrow_upward
-2
arrow_downward

Развертывание веб-приложений с помощью веб-инструмента копирования
Текст из книги Microsoft Training Kit «Веб-разработка»
Проекты веб-настройки полезны, если вы предоставляете веб-приложение многим пользователям (например, , позволяя людям загружать приложение из Интернета и устанавливать его). Если вы отвечаете за обновление определенного веб-сайта для своей организации, нецелесообразно входить на веб-сервер и устанавливать пакет установщика Windows каждый раз, когда вы делаете обновление. Для внутренних приложений вы можете редактировать веб-приложение прямо на веб-сервере. Однако внесенные вами изменения немедленно внедряются в ваше рабочее веб-приложение, и это включает в себя любые ошибки, которые могут там присутствовать. Чтобы позволить себе протестировать веб-приложение, вы можете отредактировать локальную копию веб-приложения на своем компьютере и опубликовать изменения на рабочем веб-сервере с помощью инструмента «Копировать веб». Вы также можете использовать инструмент Copy Web для публикации изменений с промежуточного сервера на производственный веб-сервер или между любыми двумя веб-серверами. Инструмент «Копировать веб-сайт» может копировать отдельные файлы или весь веб-сайт на исходный веб-сайт и удаленный веб-сайт или с них. Вы также можете выбрать синхронизацию файлов, что включает в себя копирование только измененных файлов и обнаружение возможных конфликтов управления версиями, при которых один и тот же файл на исходном и удаленном сайте редактировался отдельно. Инструмент «Копировать Интернет» не может объединять изменения в одном файле; можно копировать только полные файлы.

person Muhammad Akhtar    schedule 10.06.2009
comment
Среда, с которой я работаю чаще всего, разделена на 5 выделенных веб-серверов. Мы ищем повторяемый и простой путь развертывания, тем более что у нас нет доступа к средам выпуска или производственной среде (среды 4 и 5 на пути развертывания). Таким образом, в основном мы выполняем развертывание для многих пользователей. :-) - person Hooloovoo; 10.06.2009

arrow_upward
3
arrow_downward

У нас есть выделенные серверы DEV, TEST, STAGE и PRODUCTION.

У нас также есть специальная сборочная машина, на которой работает круиз-контроль.

Круиз-контроль настроен для сборки с непрерывной интеграцией, которая запускается после регистрации кода. Он также настроен для отдельных задач «Разработка», «Контроль качества», «Этап» и «Производство».

Для развертывания для разработки код сначала извлекается из SVN и создается, затем папка «Precompiled Web» копируется на веб-сайт разработки, а проект веб-службы копируется на сервер приложений разработки. Круиз-контроль также настроен так, чтобы «пометить» исходный код перед запуском сборки, чтобы мы могли воспроизвести сборку позже, или перейти от тега, если нам нужно сделать оперативное исправление.

Для развертывания в QA файлы копируются с машин разработки на машины QA.

Аналогичным образом, для развертывания в Stage файлы копируются с машин QA на машины Stage.

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

Для настройки каждой среды у нас есть специальный инструмент, который является частью задачи круиз-контроля каждой среды, которая изменяет строки подключения, «debug = true | false», «customErrors = Off | RemoteOnly» и другие параметры, зависящие от среды.

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

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

Наконец, позвольте мне добавить, что, хотя наши производственные машины находятся на выделенном хостинге, серверы доступны с нашей машины круиз-контроля, что очень упрощает производственное развертывание. Единственный шаг вручную - это зашифровать файлы web.config и удалить файл «AppOffline.html», созданный Круиз-контролем.

Дайте мне знать, если это поможет или у вас возникнут вопросы.

Спасибо!

person Steve J    schedule 10.06.2009
comment
Как получить доступ с производственных машин на хостинге с машины CC? (UNC, FTP и т. Д.)? - person RyanW; 19.09.2009
comment
Каким-то образом производственные машины были доступны в локальной сети, но только с определенных машин (одна из которых - круиз-контроль). Я больше не в этой компании, поэтому у меня больше нет прямого доступа к системному администратору, чтобы задать вопрос. Таким образом, развертывание происходило так, как если бы оно просто копировало файлы на другой компьютер в сети. Я считаю, что использовались пути UNC. - person Steve J; 21.09.2009

arrow_upward
0
arrow_downward

Я сделал следующее:

1) Используйте проект веб-развертывания, чтобы скомпилировать и очистить сборку, а также выполнить замену раздела web.config, если конфигурация изменяется между средами. 2) Используйте NAnt для многократного построения, архивирования и копирования.

В итоге проект веб-развертывания создает файл MSBuild, который можно использовать вместо NAnt; однако я работал с Java и все время использовал Ant, поэтому я предпочитаю NAnt в .Net. Если вы добавите задачи NAnt Contrib, вы сможете развертывать не только файлы, но и обрабатывать такие элементы, как исходный элемент управления (если он не является частью задач по умолчанию) и выполнение сценария Sql для изменений.

В настоящее время я использую оба варианта вместе. У меня есть файл сборки NAnt, который вызывает проект веб-развертывания через MSBuild. Благодаря настройке диспетчера конфигурации для каждой среды он позволяет мне автоматически управлять заменой раздела web.config и при этом иметь достаточно приличный контроль над копированием и архивированием выпуска.

Надеюсь это поможет.

person JamesEggers    schedule 10.06.2009
comment
В настоящее время мы используем TeamCity от JetBrains, и я позволил кому-то другому настроить скрипты сборки! Это довольно просто, и мы используем MSBuild на сервере CI. Я также использую проект веб-развертывания, чтобы обеспечить правильную сборку сайта, но иногда бывает немного сложно настроить его правильно. - person Hooloovoo; 10.06.2009
comment
Я знаю, что вы имеете в виду, говоря о правильной настройке сборки. В итоге я по умолчанию настроил среду Configuration Manager для каждой развернутой среды, которая у меня есть, а затем использовал проект веб-развертывания для создания под каждой из них (автоматизированный с использованием NAnt или файла сборки сервера CI). Если требуется дополнительная очистка / манипуляции, я либо отредактирую файл WDproj (msbuild) напрямую, либо сделаю обновления в NAnt. Поскольку вы не пишете файлы сборки CI для TeamCity, wdproj будет вашим лучшим выбором. Помимо этого, посмотрите, какие болевые точки есть в каждой среде, и сосредоточьтесь на них. - person JamesEggers; 10.06.2009

arrow_upward
0
arrow_downward

Мы используем проекты веб-развертывания и проекты VS 2008 для создания .msi-файла на основе результатов веб-развертывания и других проектов. Обычное приложение для Windows под названием «установка» используется для выполнения многих операций по созданию базы данных и подготовки, а не для настройки проектов установки с помощью специальных шагов. Сделать это самому намного проще, чем пытаться настроить код MS. Затем это приложение Windows вызывает нужные файлы .msi, которые нужны пользователю.

Сборка Team Foundation запускается каждый вечер, чтобы перестроить решение и скопировать все в каталог «Release CD», к которому любой может получить доступ и провести тестирование последнего «выпуска». Честно говоря, сборка TFS - это немного за бортом для такой небольшой команды, как наша, и я использую ее только потому, что это то, к чему я привык.

В предыдущей компании мы использовали этот http://www.finalbuilder.com/, и я могу рекомендовать его для простота использования и количество поддерживаемого программного обеспечения.

person simon831    schedule 10.06.2009

arrow_upward
0
arrow_downward

1) Соберите проект с помощью MSBUILD

2) FTP-файлы в производственную среду

3) Скопируйте / вставьте вручную на каждый веб-сервер

person Ken Burkhardt    schedule 10.06.2009
comment
Проблема в том, что у нас нет доступа за пределы третьей среды, поэтому нам нужно максимально автоматизировать. С точки зрения корпоративного брендинга это тоже не очень хорошо. Сказав, что это в значительной степени то, чем мы занимались последние несколько лет! - person Hooloovoo; 11.06.2009

arrow_upward
0
arrow_downward

Для сайтов интрасети мы используем CruiseControl в сочетании с SVN для автоматического восстановления сайта.

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

person Darth Continent    schedule 10.06.2009