O Windows Installers para aplicativos corporativos internos faz sentido?

Estou tentando construir um entendimento geral do que é comum nessa situação, para que eu possa decidir se faz sentido prosseguir.

1. Os instaladores são bem-vindos em um ambiente corporativo típico com o seguinte?
   • Processo de controle de alterações
   • Ambientes de desenvolvimento / controle de qualidade / produção
   • Designar equipes de implantação para várias áreas (firewall, banco de dados, janelas etc.).
2. Existe um "teste decisivo" que possa ser aplicado a um aplicativo para ver se ele é um bom candidato para a criação de um instalador? *
   • Os instaladores são simples o suficiente para que cada aplicativo tenha um?
   • Os instaladores são a ferramenta certa?
3. É razoável esperar que os desenvolvedores aprendam algo como o WiX para dar suporte aos instaladores?
   • A manutenção em geral é uma preocupação, ou seja, criar um instalador é uma habilidade de nicho?

*

Por exemplo, eu tenho um conjunto de aplicativos winform que estão em um diretório compartilhado em um servidor de produção. Grupos específicos podem executar os aplicativos nesse diretório, mas apenas os administradores do sistema podem modificar os executáveis. O processo de implantação atual envolve a instalação de um administrador para copiar / colar os executáveis ​​e as bibliotecas no diretório compartilhado.

Como os aplicativos não estão instalados na máquina de usuários individuais, faz sentido criar um instalador para implantar novas versões desses aplicativos no diretório compartilhado?

Editar--

Eu senti que as respostas aqui deram alguns conselhos sólidos, então eu queria compartilhar o que eu criei para o meu projeto atual, onde eu precisava criar um grande número de aplicativos e implantá-los em pastas individuais.

Encontrei um pacote NuGet chamado _PublishedApplications que imita o comportamento de _PublishedWebsites para projetos da web. A idéia é instalar o pacote NuGet em seus projetos e adicionar um destino que copiará os artefatos de construção em um diretório _PublishedApplications no caminho de saída. Esse comportamento é ativado executando o MSBuild na linha de comando e especificando uma outdirpropriedade:

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

Isso fornecerá uma estrutura de diretórios semelhante à seguinte:

• C: \ caminho \ para \ fora
  • _PublishedApplications \
    • Projeto 1\
      • dlls, exes, etc.
    • Projeto2 \
      • ...

A partir daí, criar um zip que pode ser extraído nos vários ambientes é bastante simples.

Um instalador sempre faz sentido, se a implantação exigir algo mais complicado do que copiar o (s) arquivo (s) relevante (s) para alguma pasta e executar o EXE. Se forem necessárias etapas adicionais para configurar o produto corretamente, há duas maneiras de fazê-lo.

1. Você pode escrever uma lista para alguém seguir. Humanos sendo humanos, alguém pode estragar tudo e depois ligar para você pedindo ajuda, porque seu programa não está funcionando corretamente.
2. Você pode escrever uma lista para um computador seguir (um script de instalação). Isso torna muito menos provável que o erro do usuário estrague a implantação.

Por outro lado, se você não tiver nenhuma tarefa de configuração que precise ser executada, basta fornecer um arquivo zip. Isso é mais simples do que executar um instalador.

Wyatt tira seu chapéu de programador e veste seu chapéu de diretor de TI

Se essa é uma linha interna de aplicativo de negócios, você precisa apenas visar um ambiente - disse o negócio. Telefonaria para o chefe de TI e perguntaria como eles gostariam de gerenciar a implantação. Os departamentos de TI lidam com isso há algum tempo, portanto, eles podem ter uma forte preferência por opções baseadas em xcopy ou MSI ou em algo totalmente diferente, como a sua opção atual.

Acrescentarei que o departamento apreciaria pelo menos o gesto e provavelmente se tornaria um aliado valioso, pois é provável que eles saibam mais sobre a linha de aplicativos de negócios e os problemas existentes do que você imagina.

Os aplicativos Windows Installer são amplamente usados ​​para instalar aplicativos corporativos internos em ambientes usando o Windows. Você também deve se perguntar se, durante a vida do aplicativo, ele provavelmente precisará ser atualizado, corrigido, reparado ou removido de forma limpa dos sistemas do usuário. Em muitos casos, a resposta é "sim" - nesse caso, ter um instalador devidamente escrito pode reduzir o custo total de manutenção do aplicativo ao longo do tempo. Existem outros serviços e recursos projetados para funcionar com o Windows Installer, como o Restart Manager e o WMI e as funções de inventário de produtos e patches. Se seu aplicativo pode se beneficiar com isso, esse é outro motivo para incluir um instalador.

Os custos iniciais para desenvolver um instalador útil para o seu aplicativo podem render a longo prazo, e os custos de desenvolvimento podem ser atenuados selecionando uma ferramenta de criação apropriada do Windows Installer, como WiX ou InstallShield ou outro.

Como em todas as decisões de engenharia, isso depende.

Provavelmente, o fator mais importante é entender quem é o consumidor do seu processo de instalação e qual o conjunto de habilidades da equipe de desenvolvimento.

Por ser interno, presumo que ele tenha sido implantado por um departamento de TI interno. Provavelmente não são estranhos para comandar conchas.

Os assistentes de instalação gráfica são úteis para softwares distribuídos diretamente a clientes externos, porque as premissas simples sobre sua configuração não são mais válidas, como locais de servidores de arquivos, políticas de segurança etc.

No seu ambiente, essas coisas provavelmente são ditadas pelo desenvolvimento ou pela TI e raramente mudam. Portanto, recomendo usar scripts de shell para copiar arquivos para o local apropriado. Os scripts devem residir no seu produto como parte do pacote lançado. Também deve ser controlado por versão junto com seu aplicativo.

Onde trabalho, nosso aplicativo Web inteiro é instalado por meio de um assistente InstallShield, que faz várias perguntas, a maioria sobre locais de sistema de arquivos, informações de conexão db e outras configurações que acabam nos arquivos de configuração. É difícil de automatizar. Como a instalação do aplicativo Web em sua essência acabou de criar alguns bancos de dados e copiar arquivos, estou escrevendo um novo instalador usando o Ant ou o Powershell que simplesmente executa arquivos .sql e copia arquivos.

Então todos podem entender como funciona e mantê-lo com mais eficiência.