Имеют ли смысл установщики Windows для внутренних бизнес-приложений?

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

1. Приветствуются ли установщики в типичной корпоративной среде со следующим?
   • Изменить процесс управления
   • Dev / QA / Производственные среды
   • Назначенные группы развертывания для различных областей (межсетевой экран, база данных, окна и т. Д.).
2. Существует ли «лакмусовая бумажка», которая может быть применена к приложению, чтобы увидеть, является ли оно хорошим кандидатом для создания установщика? *
   • Являются ли установщики достаточно простыми, чтобы у каждого приложения был такой?
   • Являются ли установщики подходящим инструментом?
3. Разумно ли ожидать, что разработчики узнают что-то вроде WiX для поддержки установщиков?
   • Техническое обслуживание в целом является проблемой, т. Е. Создает ли установщик нишевые навыки?

*

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

Поскольку приложения не установлены на компьютере отдельных пользователей, имеет ли смысл создавать установщик для развертывания новых версий этих приложений в общем каталоге?

Редактировать--

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

Я нашел пакет NuGet под названием _PublishedApplications, который имитирует поведение _PublishedWebsites для веб-проектов. Идея заключается в том, что вы устанавливаете пакет NuGet в свои проекты, и он добавляет цель, которая будет копировать артефакты сборки в каталог _PublishedApplications в выходном пути. Это поведение активируется запуском MSBuild из командной строки и указанием outdirсвойства:

msbuild /p:Configuration=Release /p:outdir=C:\path\to\outdir MySolution.sln

Это даст вам структуру каталогов, подобную следующей:

• C: \ путь \ к \ OutDir
  • _PublishedApplications \
    • Project1 \
      • dlls, exes, etc.
    • Проект2 \
      • ...

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

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

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

С другой стороны, если у вас нет задач по настройке, которые нужно выполнить, просто дайте им zip-файл. Это проще, чем запускать установщик.

Уайетт снимает шляпу программиста и надевает шляпу директора по ИТ

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

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

Приложения установщика Windows широко используются для установки внутренних бизнес-приложений в средах с использованием Windows. Вы также должны спросить себя, будет ли приложение обновляться, исправляться, исправляться или удаляться из пользовательских систем в течение жизни. Во многих случаях ответом является «да» - в этом случае наличие надлежащим образом написанного установщика может сократить общую стоимость обслуживания приложения с течением времени. Существуют и другие службы и функции, предназначенные для работы с установщиком Windows, такие как Restart Manager и WMI, а также функции инвентаризации продуктов и исправлений. Если ваше приложение может извлечь из этого пользу, это еще одна причина для включения установщика.

Первоначальные затраты на разработку полезного установщика для вашего приложения могут окупиться в долгосрочной перспективе, а затраты на разработку можно уменьшить, выбрав подходящий инструмент разработки для установщика Windows, например WiX, InstallShield или другой.

Как и во всех инженерных решениях, это зависит.

Вероятно, наиболее важным фактором является понимание того, кто является потребителем вашего процесса установки и какими навыками обладает команда разработчиков.

Поскольку он внутренний, я предполагаю, что он развернут внутренним ИТ-отделом. Они, вероятно, не чужие командовать снарядами.

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

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

Там, где я работаю, все наше веб-приложение устанавливается с помощью мастера InstallShield, который задает кучу вопросов, большинство из которых - местоположения файловой системы, информация о подключении к БД и другие параметры, которые в итоге оказываются в файлах конфигурации. Это сложно автоматизировать. Поскольку установка веб-приложения по своей сути только что создала пару баз данных и копирует файлы, я пишу новый установщик, использующий либо Ant, либо Powershell, который просто запускает файлы .sql и копирует файлы.

Тогда каждый сможет понять, как это работает, и поддерживать его более эффективно.