Gli installatori di Windows per applicazioni aziendali interne hanno senso?

Sto cercando di costruire una comprensione generale per ciò che è comune in questa situazione in modo da poter decidere se ha senso proseguire ulteriormente.

1. Gli installatori sono i benvenuti in un tipico ambiente aziendale con quanto segue?
   • Processo di controllo delle modifiche
   • Ambienti Dev / QA / Production
   • Team di distribuzione designati per varie aree (firewall, database, finestre, ecc.).
2. Esiste un "tornasole" che potrebbe essere applicato a un'applicazione per vedere se è un buon candidato per la creazione di un programma di installazione? *
   • Gli installatori sono abbastanza semplici che ogni applicazione dovrebbe averne uno?
   • Gli installatori sono anche lo strumento giusto?
3. È ragionevole aspettarsi che gli sviluppatori imparino qualcosa come WiX per supportare gli installatori?
   • La manutenzione in generale è una preoccupazione, vale a dire, la creazione di un installatore è un'abilità di nicchia?

*

Ad esempio, ho un set di applicazioni winform che si trovano in una directory condivisa su un server di produzione. Gruppi specifici possono eseguire le applicazioni da questa directory, ma solo gli amministratori di sistema possono modificare gli eseguibili. L'attuale processo di distribuzione prevede che un amministratore copi / incolli gli eseguibili e le librerie nella directory condivisa.

Poiché le applicazioni non sono installate sul computer dei singoli utenti, ha senso creare un programma di installazione per distribuire nuove versioni di queste applicazioni nella directory condivisa?

Modificare--

Ho sentito che le risposte qui davano alcuni solidi consigli, quindi volevo condividere ciò che mi è venuto in mente per il mio attuale progetto in cui avevo bisogno di costruire un gran numero di applicazioni e distribuirle in singole cartelle.

Ho trovato un pacchetto NuGet chiamato _PublishedApplications che imita il comportamento di _PublishedWe website per progetti Web. L'idea è di installare il pacchetto NuGet nei progetti e di aggiungere una destinazione che copierà gli artefatti di compilazione in una directory _PublishedApplications nel percorso di output. Questo comportamento si attiva eseguendo MSBuild dalla riga di comando e specificando una outdirproprietà:

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

Questo ti darà una struttura di directory simile alla seguente:

• C: \ percorso \ a \ outdir
  • _PublishedApplications \
    • Project1 \
      • dlls, exes, etc.
    • Project2 \
      • ...

Da lì, creare una zip che può essere estratta nei vari ambienti è abbastanza indolore.

Un installatore ha sempre senso, se la distribuzione richiede qualcosa di più complicato della copia dei file pertinenti in alcune cartelle e dell'esecuzione di EXE. Se sono necessari ulteriori passaggi per configurare correttamente il prodotto, esistono due modi per procedere.

1. Puoi scrivere un elenco per qualcuno da seguire. Gli esseri umani sono umani, qualcuno è destinato a rovinare tutto e poi ti chiama per chiedere aiuto perché il tuo programma non funziona correttamente.
2. È possibile scrivere un elenco da seguire per un computer (uno script di installazione). Ciò rende molto meno probabile che l'errore dell'utente rovini la distribuzione.

D'altra parte se non hai attività di installazione che devono essere eseguite, dai semplicemente un file zip. È più semplice che eseguire un programma di installazione.

Wyatt si toglie il cappello da programmatore e indossa il cappello da direttore IT

Se si tratta di una linea interna di applicazione aziendale, è necessario puntare solo su un ambiente, detto business. Vorrei chiamare il responsabile IT e chiedergli come vorrebbero gestire la distribuzione. I dipartimenti IT si occupano di questo da un po 'di tempo, quindi potrebbero avere una forte preferenza per le opzioni xcopy o basate su MSI o qualcos'altro come l'opzione corrente.

Aggiungerò che il dipartimento apprezzerebbe per lo meno il gesto e potrebbe probabilmente diventare un valido alleato in quanto è probabile che sappiano di più sulla linea esistente di app e problemi di quanto tu possa immaginare.

Le applicazioni di Windows Installer sono ampiamente utilizzate per installare applicazioni aziendali interne in ambienti che utilizzano Windows. Dovresti anche chiederti se per tutta la vita dell'applicazione sarà probabilmente necessario aggiornare, patchare, riparare o rimuovere in modo pulito dai sistemi dell'utente. In molti casi la risposta è "sì" - nel qual caso avere un programma di installazione scritto correttamente può ridurre il costo totale di gestione dell'applicazione nel tempo. Esistono altri servizi e funzionalità progettati per funzionare con Windows Installer, come Restart Manager e WMI e funzioni di inventario di prodotti e patch. Se l'applicazione può trarne vantaggio, questo è un altro motivo per includere un programma di installazione.

I costi iniziali per lo sviluppo di un utile programma di installazione per l'applicazione potrebbero essere ripagati a lungo termine e i costi di sviluppo possono essere mitigati selezionando uno strumento di creazione di Windows Installer appropriato, come WiX o InstallShield o un altro.

Come per tutte le decisioni di ingegneria, dipende.

Probabilmente il fattore più importante è capire chi è il consumatore del processo di installazione e quali competenze ha il team di sviluppo.

Dal momento che è interno, suppongo sia distribuito da un dipartimento IT interno. Probabilmente non sono estranei a comandare shell.

Le procedure guidate di installazione grafica sono utili per il software che viene distribuito direttamente ai clienti esterni perché i semplici presupposti sulla configurazione non sono più validi, come posizioni dei file server, politiche di sicurezza, ecc. Pertanto, è necessario guidare ciascun utente attraverso la selezione delle impostazioni stesse.

Nel tuo ambiente, questa roba è probabilmente dettata dallo sviluppo o dall'IT e raramente cambia. Pertanto, consiglio di utilizzare gli script di shell per copiare i file nel posto appropriato. Gli script dovrebbero trovarsi all'interno del tuo prodotto come parte del pacchetto che viene rilasciato. Dovrebbe anche essere controllato con la versione insieme alla tua app.

Dove lavoro, la nostra intera applicazione Web viene installata tramite una procedura guidata InstallShield, che pone una serie di domande, la maggior parte delle quali sono posizioni del file system, informazioni sulla connessione db e altre impostazioni che finiscono nei file di configurazione. È difficile da automatizzare. Poiché l'installazione dell'app web al suo interno ha appena creato un paio di database e copia file, sto scrivendo un nuovo programma di installazione utilizzando Ant o Powershell che esegue semplicemente file .sql e copia file.

Quindi tutti possono capire come funziona e mantenerlo in modo più efficace.