Quali tecnologie di implementazione hanno senso nella distribuzione continua?

Suggerirei un processo in due fasi. Costruire crea il programma di installazione, che esce sul tuo server. Le macchine client sono configurate per estrarre il programma di installazione all'avvio / mezzanotte / finestra di manutenzione ed eseguirlo silenziosamente.

Quindi continui a costruire durante il giorno, ma i sistemi live catturano il nuovo programma di installazione al momento opportuno. Non è tanto questione di avere una sola cosa fare tutto il lavoro del ciclo build / deploy. Il punto è avere tutto automatizzato che è un animale diverso.

L'esempio classico è che un robot cucina un pasto. La maggior parte delle persone inizia a progettare il modo in cui il robot aprirà la porta del frigorifero, controllerà la produzione in base alla sensazione, così via e così via. Ma un design adeguato getta il concetto di una cucina! Un robot per cucinare sarebbe l'intera stanza. Ci sarebbe una parte che apre il prodotto pre-confezionato, già determinato corretto, e lo sposta tramite un nastro trasportatore alla stufa. Alla stufa, più bracci con utensili incorporati avrebbero iniziato a montare il prodotto in uscita. La cosa non ha bisogno di mani, non ha bisogno di gambe, quasi non ha bisogno di occhi.

Il tuo sistema di costruzione non dovrebbe essere: "prendere ciò che una persona farebbe / fa attualmente e fare in modo che un programma lo attraversi esattamente". Inizia da ciò che vuoi realizzare . Quando il tuo processo viene eseguito, la distribuzione viene eseguita, ovunque tu abbia definito tale.

Dato che hai menzionato Windows Installer e MSI, immagino che ti interessi principalmente nella distribuzione di app client / desktop? La distribuzione automatica allo stesso server di build dovrebbe essere relativamente semplice (attivando un'installazione invisibile come suggerito da altri poster) - a scopo di test ciò avrebbe senso solo per le app del server (o in un team veramente piccolo dove il tester stava usando il server di build stesso).

La soluzione migliore che posso pensare se vuoi spingere l'installazione sui propri computer dei tester è usare la distribuzione dei criteri di gruppo sul dominio per implementare le build (vedi link ) Questo richiederà un passaggio manuale per pubblicare l'aggiornamento, che non è l'ideale per i tuoi scopi (se un po 'importante per la sicurezza della rete :-)) Richiede anche di avere privilegi di amministratore sul controller di dominio, che potrebbe essere un fattore limitante a seconda la dimensione / struttura della tua organizzazione!

Un ottimo esempio da cui guardare / rubare è google chrome - fanno una distribuzione continua e silenziosa su Windows. Senza richiedere l'approvazione dell'amministratore.

Il trucco principale, come comprendo, è semplicemente l'utilizzo della distribuzione Microsoft Click-Once combinata con la distribuzione in% userprofile% piuttosto che% programfiles% ma potrei sbagliarmi.

Generalmente il problema è che non si desidera distribuire continuamente se la casella di test è in uso, immagina la carneficina mentre i tester registrano i bug contro la v567 dell'app, ma in realtà sono (silenziosamente) in esecuzione v568!

Quindi, non ho mai effettivamente distribuito continuamente. Applico l'app (e copio tutti i file binari in directory pertinenti in modo che gli utenti possano sceglierne uno particolare se necessario) e li autorizzi a installarsi. Di solito fanno quella prima cosa al mattino, tramite una sceneggiatura.

Gli MSI possono essere installati in modalità silenziosa (in cui è sufficiente avviare l'EXE e lasciarlo terminare). Questo sarebbe ottimo per la modalità non presidiata.

Se è effettivamente necessario test l'installer, prendere in considerazione la possibilità di scrivere un robot in grado di "assaggiare" ciò che è sul monitor, individuare i pulsanti e premerli e inserire il testo nei campi di testo. In altre parole, come faresti blackbox per testare qualsiasi altra applicazione della GUI.

Abbiamo configurato il nostro server di build per spingere le risorse in un repository SVN. I tester lavorano tutti da una copia verificata di quel repository e quando hanno bisogno / vogliono / dicono di aggiornarlo è semplicemente una questione di loro facendo clic con il pulsante destro sulla directory di livello superiore e selezionando Aggiorna (TortoiseSVN).