Какой метод вы используете для развертывания приложений ASP.Net в дикой природе?
В настоящее время мы развертываем скомпилированные приложения ASP.Net, публикуя веб-сайт локально и отправляя по электронной почте zip-файл системному администратору с (как правило) длинным набором инструкций для развертывания. Это связано с тем, что в первый раз, когда мы применили приложение ASP.Net к клиенту, демон и тестовый экземпляр IIS были одинаковыми, и мы не смогли дважды развернуть сайт на одном компьютере. Это задает тон для развертывания во всех последующих проектах.
Теперь я оцениваю наши методы развертывания и я смотрю конкретно на встроенные инструменты развертывания; в частности, я рассматриваю пользовательские задачи установки и использую как можно больше стандартных возможностей установщика (в основном, пользовательский интерфейс).
Во-вторых, я смотрю на объединение развертываний и автоматических обновлений.
- Лучшие практики ILMerge
- Лучший способ развертывания приложения Visual Studio, которое может работать без установки
- Как вручную установить веб-сервис на Tomcat 6?
- Определение версии сборки во время события после сборки
- ASP.NET MVC на IIS6
Как вы собираетесь развертывать программное обеспечение в своей организации? Какие инструменты вы используете, и какие проблемы вы чаще всего встречаете?
- Универсальный ЭЛТ-модуль MSVC 2015 для локального развертывания приложений
- Установите службу Windows .NET без InstallUtil.exe
- Создание Windows Installer для программ на Java
- Как развернуть SQL Server Compact Edition 4.0?
- Использование Maven для развертывания
- Горячее развертывание на JBoss - как мне заставить JBoss «видеть» изменение?
- Существует ли компилятор R?
- Android Studio не развертывает изменения в приложении
Развертывание веб-приложений с помощью инструмента «Копировать Web»
Текст из Microsoft Training Kit Book Веб-разработка
Проекты веб-настройки полезны, если вы предоставляете веб-приложение для многих пользователей (например, позволяя пользователям загружать приложение из Интернета и устанавливать его). Если вы несете ответственность за обновление определенного веб-сайта для своей организации, нецелесообразно регистрироваться на веб-сервере и устанавливать пакет установщика Windows при каждом обновлении. Для внутренних приложений вы можете редактировать веб-приложение непосредственно на веб-сервере. Однако сделанные вами изменения немедленно реализуются в вашем веб-приложении для производства, и это включает в себя любые ошибки, которые могут быть там. Чтобы вы могли протестировать веб-приложение, вы можете отредактировать локальную копию веб-приложения на своем компьютере и опубликовать изменения на веб-сервере производства с помощью инструмента «Копирование веб-страниц». Вы также можете использовать инструмент «Копировать веб» для публикации изменений с промежуточного сервера на веб-сервере производства или между любыми двумя веб-серверами. Средство Copy Web может копировать отдельные файлы или весь веб-сайт на исходный веб-сайт и удаленный веб-сайт или с него. Вы также можете синхронизировать файлы, которые include в себя копирование только измененных файлов и обнаружение возможных конфликтов версий, в которых один и тот же файл как на исходном, так и на удаленном сайтах был отдельно отредактирован. Средство Copy Web не может объединять изменения в одном файле; можно скопировать только полные файлы.
Мы выделили серверы DEV, TEST, STAGE и PRODUCTION.
У нас также есть специальная сборная машина, в которой работает Cruise Control.
Круиз-контроль настроен для сборки непрерывной интеграции, которая запускается после проверки кода. Она также настроена для отдельных задач разработки, QA, Stage и Production.
Для развертывания в разработке код сначала извлекается из SVN и строится, затем папка «Предварительно скомпилированная сеть» копируется на веб-сайт разработки, а проект веб-службы копируется на сервер приложений разработки. Круиз-контроль также настроен на «tagsровать» исходный код до начала сборки, чтобы мы могли позже воспроизвести сборку или разветвиться с тегом, если нам нужно сделать горячее исправление.
Для развертывания в QA файлы копируются с машин разработки на машины QA.
Аналогично, для развертывания на этапе файлы копируются из машин QA в машины Stage.
Наконец, для развертывания в производство файлы снова копируются с машин Stage на производственные машины.
Для настройки каждой среды у нас есть настраиваемый инструмент, который является частью задачи Cruise Control каждой среды, которая изменяет строки подключения «debug = true | false», «customErrors = Off | RemoteOnly» и другие параметры, относящиеся к среде.
Таким образом, каждую среду можно развернуть с помощью кнопочного нажатия с панели управления Cruise Control.
Одно из предостережений заключается в том, что в настоящее время у нас есть пароль базы данных производства, сконфигурированный в конфигурационном файле Cruise Control … было бы неплохо двигаться в другом месте!
Наконец, позвольте мне добавить, что даже если наши производственные машины находятся в выделенном хостинге, серверы доступны с нашей машины для круиз-контроля, что упрощает развертывание производства. Единственный ручной шаг – зашифровать файлы web.config и удалить файл AppOffline.html, который запускает Cruise Control.
Дайте мне знать, если это поможет, или если у вас есть вопросы.
Благодаря!
1) Построить проект с MSBUILD
2) Файлы FTP для производственной среды
3) Копировать / Вставить вручную на каждый веб-сервер
Несколько вещей, которые я сделал, это следующее:
1) Используйте проект веб-развертывания, чтобы скомпилировать и очистить сборку, а также передать раздел раздела web.config, если конфигурация изменяется между средами. 2) Используйте NAnt для повторного создания всего здания, архивирования и копирования.
Проект Web Deployment Project создает файл MSBuild, который можно использовать вместо NAnt; однако я пришел из фона Java и все время использовал Ant, поэтому NAnt – мое предпочтение в .NET. Если вы добавите в задачи NAnt Contrib, вы сможете развернуть не только файлы, но и обработать такие элементы, как ваш исходный элемент управления (если он не является частью задач по умолчанию) и Sql Script Execution для изменений.
В настоящее время я использую оба варианта вместе. У меня есть файл сборки NAnt, который вызывает проект веб-развертывания через MSBuild. С настройкой менеджера конфигурации для каждой среды он позволяет автоматически управлять секциями раздела web.config и все еще иметь довольно приличный контроль над моим копированием и архивированием выпуска.
Надеюсь это поможет.
Мы используем проекты веб-развертывания и проекты VS 2008 для создания .msi из результатов веб-развертывания и других проектов. Обычное приложение Windows, называемое «setup», используется для создания большого количества созданных db и предварительных материалов, вместо того, чтобы пытаться настроить проекты установки с помощью настраиваемых шагов. Гораздо проще сделать это самостоятельно, чем пытаться настроить код MS. Затем это приложение Windows вызывает правильные .msi-файлы, которые нужны пользователю.
Team Foundation Build запускается каждый вечер, чтобы перестроить решение и скопировать все в каталог «Release CD», который каждый может получить и выполнить тестирование в последней версии. Честно говоря, assembly TFS немного за борт для небольшой команды, такой как наша, и я использую ее только потому, что я ее использую.
В предыдущей компании мы использовали этот http://www.finalbuilder.com/, и я могу порекомендовать его для удобства использования и количества поддерживаемого программного обеспечения.
Для сайтов интрасети мы используем CruiseControl совместно с SVN для автоматического восстановления сайта.
Теоретически вы можете расширить эту модель по VPN, если бы вы могли удаленно отображать диск в интрасети клиента. Или более быстрым и грязным решением может быть использование инструмента, такого как SyncBack, для синхронизации удаленной папки, содержащей скомпилированные библиотеки DLL для сайта.