Кто-нибудь создает инсталляторы для развертывания внутренних веб-приложений asp.net?

Question

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

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

Но мне любопытно; Кто-нибудь создает установщики для развертывания внутренних веб-приложений asp.net?

Если так, то почему? (Добровольно, по поручению или в рамках процесса автоматизации)

А у вас были какие-то проблемы с этим?

Answer 1

абсолютно. Мы используем его, чтобы сделать все наши приложения. Таким образом, мы создаем установщик и запускаем его в средах qa и uat для тестирования, и мы точно знаем, что произойдет на производстве. Нет никаких предположений относительно того, в каком порядке кто-то может сделать что-то, или если они пропустят шаг. Это делает вещи намного проще.

Ох, я тоже забыл про автоматизированный процесс. У нас есть системы (Ant Hill Pro), которые автоматически развертывают их в соответствующих средах. Люди не должны ждать, пока что-то будет сделано, потому что все это делается в 2 часа ночи. Если им необходимо повторно запустить сборку с обновлениями, разработчики проверяют код, и мы нажимаем кнопку, и она автоматически развертывается. Не нужно ждать инженера-строителя, потому что он на совещании или болен или что-то в этом роде.

Answer 2

Вы всегда хотите иметь автоматизированный способ построения и развертывания - это значительно снижает вероятность одноразовой ошибки, если вы забудете определенный шаг. Кроме того, он позволяет легко перенести развертывание на кого-то другого, не обучая его 100 индивидуальным шагам. Независимо от того, является ли проект внутренним или нет, все приложения должны следовать передовым методам.

Answer 3

Это сильно зависит от масштаба вашего проекта, вашей среды и вашей внутренней базы пользователей. Я редко внедряю с MSI, потому что мы слишком малы, чтобы иметь несколько сред (кроме SharePoint, все вместе). Мы разрабатываем и используем VS для развертывания веб-приложений в блоке разработки, при условии, что они одобрены, а затем снова используем VS для развертывания в оперативном окне.

Единственное условие - у нас есть несколько копий файла web.config (с добавлением test, dev и live), а затем мы удаляем суффикс из соответствующего файла в зависимости от того, где он был развернут.

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

Answer 4

Да ... у нас есть приложение, которое требует много предварительных требований .... веб-сервис, служба Windows, учетные записи пользователей, безопасность, создание папок, биты GAC и т. Д. в хороший MSI с пользовательскими действиями, которые можно устанавливать и удалять чисто. Для развертывания на новой коробке сэкономлено около часа работы.

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

Answer 5

Здесь мы используем модель развертывания «XCopy», поскольку у сотрудников Ops есть собственный метод настройки безопасности для нового веб-приложения на сервере.

Однако нам нужно было использовать установщик, когда нам нужно было установить веб-приложение, которое использовало более новую версию Crystal Reports, поскольку оно должно было делать что-то особенное с ключом, а у нас не было полноценной версии CR на самом сервере. Поэтому имейте в виду, что при работе со сторонними приложениями им может понадобиться какой-то модуль слияния, с которым MSI легко справится.

Answer 6

Я использую « Проект веб-установки » для создания MSI, который установил вывод « Проект веб-развертывания » для внутреннего приложения. Наш администратор сервера не выполнил задачу установки вручную из 50 шагов. Для моего текущего приложения мой администратор сервера не любит ощущение «черного ящика» установщиков MSI и предпочитает получать кучу файлов и руководство по развертыванию из 50 шагов. (См. Образец здесь? Спросите своего администратора сервера, что он хочет.)

Проект веб-установки не дает сразу понять, как установить что-либо, кроме «Веб-сайта по умолчанию», кроме этого, он сделал процесс установки повторяющимся и создал встроенный способ отката (просто запустив установщик с 1 версии назад).

Это, конечно, предполагает, что ваш виртуальный каталог не содержит какого-либо измененного пользователем содержимого - я бы не стал доверять MSI для правильного объединения созданных пользователем и новых файлов.

Answer 7

Я использую Powershell и обнаружил, что действительно легко автоматизировать множество задач. Вы, вероятно, найдете немного другое в самом начале, но в конце вы увидите, что все дело в силе библиотек .NET !!!

Answer 8

Лично я немного похож на ОП; как правило, я просто развертываю с использованием FTP, но, говоря, что мои приложения, как правило, являются внутренними, или в случае других проектов, которыми я на 100% управляю.

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

Answer 9

F5ToDebug ...

Вы говорите, что все в порядке, если у вас нет времени, чтобы делать это правильно?

"кто собирается тестировать код в тестовой среде?" Вы сами сказали, что у вас есть файлы конфигурации для _test - почему это не подходит?