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

Question

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

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

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

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

И были ли у вас какие-либо проблемы с тем, чтобы делать это таким образом?

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

Ошибка F5ToDebug...

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

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