¿Tienen sentido los instaladores de Windows para aplicaciones empresariales internas?

Estoy tratando de construir una comprensión general de lo que es común en esta situación para poder decidir si tiene sentido seguir adelante.

1. ¿Son bienvenidos los instaladores en un entorno corporativo típico con lo siguiente?
   • Proceso de control de cambios
   • Dev / QA / entornos de producción
   • Equipos de despliegue designados para diversas áreas (firewall, base de datos, ventanas, etc.).
2. ¿Existe una "prueba de fuego" que podría aplicarse a una aplicación para ver si es un buen candidato para crear un instalador? * *
   • ¿Son los instaladores lo suficientemente simples como para que cada aplicación tenga uno?
   • ¿Los instaladores son incluso la herramienta adecuada?
3. ¿Es razonable esperar que los desarrolladores aprendan algo como WiX para apoyar a los instaladores?
   • La mantenibilidad en general es una preocupación, es decir, ¿crear un instalador es una habilidad de nicho?

* *

Por ejemplo, tengo un conjunto de aplicaciones winform que se encuentran en un directorio compartido en un servidor de producción. Grupos específicos pueden ejecutar las aplicaciones desde este directorio, pero solo los administradores del sistema pueden modificar los ejecutables. El proceso de implementación actual implica que un administrador copie / pegue los archivos ejecutables y las bibliotecas en el directorio compartido.

Dado que las aplicaciones no están instaladas en la máquina de los usuarios individuales, ¿tiene sentido crear un instalador para implementar nuevas versiones de estas aplicaciones en el directorio compartido?

Editar--

Sentí que las respuestas aquí daban algunos consejos sólidos, así que quería compartir lo que se me ocurrió para mi proyecto actual donde necesitaba construir una gran cantidad de aplicaciones e implementarlas en carpetas individuales.

Encontré un paquete NuGet llamado _PublishedApplications que imita el comportamiento de _PublishedWebsites para proyectos web. La idea es instalar el paquete NuGet en sus proyectos y agrega un destino que copiará los artefactos de compilación en un directorio _PublishedApplications en la ruta de salida. Este comportamiento se activa ejecutando MSBuild desde la línea de comando y especificando una outdirpropiedad:

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

Esto le dará una estructura de directorio similar a la siguiente:

• C: \ ruta \ a \ outdir
  • _Aplicaciones publicadas \
    • Proyecto 1\
      • dlls, exes, etc.
    • Proyecto2 \
      • ...

A partir de ahí, crear un zip que se pueda extraer en los distintos entornos es bastante sencillo.

Un instalador siempre tiene sentido, si la implementación requiere algo más complicado que copiar los archivos relevantes en alguna carpeta y ejecutar el EXE. Si hay pasos adicionales que deben tomarse para configurar el producto correctamente, hay dos maneras de hacerlo.

1. Puede escribir una lista para que alguien la siga. Los humanos son humanos, alguien está obligado a arruinarlo y luego lo llamará pidiéndole ayuda porque su programa no se está ejecutando correctamente.
2. Puede escribir una lista para que la siga una computadora (un script de instalación). Esto hace que sea mucho menos probable que el error del usuario arruine la implementación.

Por otro lado, si no tiene ninguna tarea de configuración que deba realizarse, simplemente deles un archivo zip. Eso es más simple que ejecutar un instalador.

Wyatt se quita el sombrero de programador y se pone el sombrero de Director de TI

Si se trata de una aplicación de línea de negocio interna, entonces solo necesita apuntar a un entorno: dicho negocio. Llamaría al jefe de TI y le preguntaría cómo les gustaría gestionar la implementación. Los departamentos de TI han estado lidiando con esto durante un tiempo, por lo que podrían tener una fuerte preferencia por las opciones basadas en xcopy o MSI o algo completamente diferente, como su opción actual.

Agregaré que el departamento al menos apreciaría el gesto y probablemente podría convertirse en un aliado valioso, ya que es probable que sepan más sobre la línea existente de aplicaciones comerciales y los problemas de lo que crees.

Las aplicaciones de Windows Installer se usan ampliamente para instalar aplicaciones comerciales internas en entornos que usan Windows. También debe preguntarse si durante la vida útil de la aplicación es probable que alguna vez deba actualizarse, parchearse, repararse o eliminarse limpiamente de los sistemas del usuario. En muchos casos, la respuesta es "sí", en cuyo caso tener un instalador escrito correctamente puede reducir el costo total de mantenimiento de la aplicación a lo largo del tiempo. Hay otros servicios y características diseñados para funcionar con Windows Installer, como Restart Manager y WMI y funciones de inventario de productos y parches. Si su aplicación puede beneficiarse de estos, entonces esa es otra razón para incluir un instalador.

Los costos iniciales para desarrollar un instalador útil para su aplicación pueden ser rentables a largo plazo, y los costos de desarrollo pueden mitigarse seleccionando una herramienta de autoría de Windows Installer adecuada, como WiX o InstallShield u otra.

Como con todas las decisiones de ingeniería, depende.

Probablemente el factor más importante es comprender quién es el consumidor de su proceso de instalación y qué habilidades tiene el equipo de desarrollo.

Como es interno, supongo que lo implementa un departamento de TI interno. Probablemente no sean extraños para mandar proyectiles.

Los asistentes de instalación gráfica son útiles para el software que se distribuye a clientes externos directamente porque las suposiciones simples sobre su configuración ya no son válidas, como las ubicaciones del servidor de archivos, las políticas de seguridad, etc. Por lo tanto, debe guiar a cada usuario a través de la selección de la configuración.

En su entorno, estas cosas probablemente estén dictadas por el desarrollo o la TI y rara vez cambian. Por lo tanto, recomiendo usar scripts de shell para copiar archivos al lugar apropiado. Los scripts deben vivir dentro de su producto como parte del paquete que se publica. También se debe controlar la versión junto con su aplicación.

Donde trabajo, toda nuestra aplicación web se instala a través de un asistente InstallShield, que hace un montón de preguntas, la mayoría de las cuales son ubicaciones del sistema de archivos, información de conexión db y otras configuraciones que terminan en archivos de configuración. Es difícil de automatizar. Dado que la instalación de la aplicación web en su núcleo acaba de crear un par de bases de datos y copias de archivos, estoy escribiendo un nuevo instalador usando Ant o Powershell que simplemente ejecuta archivos .sql y copia archivos.

Entonces todos pueden entender cómo funciona y mantenerlo de manera más efectiva.