TFS 2010 e "costruire una volta, distribuire molti"

Question

Ho fatto un sacco di ricerche su questo argomento ma non ho trovato alcun fine a soluzione end per l'attuazione del "costruire una volta e distribuire molti" utilizzando TFS 2010.

Fondamentalmente quello che sto pensando è avere una definizione di build che costruirà una soluzione con più progetti da implementare (applicazione web + progetto di database + servizio web + report), posizionare l'output nella cartella di rilascio e da lì in base alla qualità e alla versione decidere manualmente di distribuire tutti i progetti su vari ambienti (qa, ua, staging, produzione).

So che posso modificare il modello di processo di build per distribuire più progetti subito dopo la compilazione, qualcosa come "Build Main And Deploy to QA", "Build Main and Deploy to UA" ecc., Basato probabilmente sul changeset # o etichette ma questo significa costruire ogni volta. Quello che vorrei è più simile a un dashboard che consentirà al team di distribuzione di distribuire la build esatta che è stata testata in QA, in ambiente UA e dopo aver ottenuto il via libera per la distribuzione in produzione. Ovviamente ciò significa che i file di configurazione dovrebbero essere aggiornati di conseguenza al momento dell'implementazione.

Sto anche considerando di definire alcune definizioni di build che in realtà non generano nulla, invece distribuirà una build esistente (basata sulla versione) in un ambiente specifico, ma a dir poco è un po 'strano.

Answer 1

Abbastanza vicino a ciò che usiamo, abbiamo creato modelli per realizzare build effettive e distribuito modelli che distribuiscono l'output su vari computer (questi possono essere impostati per l'esecuzione in orari pianificati, come cadute notturne al QA ecc. O su richiesta come UAT/live). I modelli sono molto modificati rispetto a quelli predefiniti, abbiamo solo analizzato i dettagli delle build (o in alcuni casi è possibile utilizzare le build più recenti come un ambiente di prova fumi) come le posizioni di rilascio.

Avrete bisogno di un agente sul computer che state distribuendo per gestire la distribuzione, ma potete installare tutti gli agenti che volete.

Ad esempio è possibile avere una build che crea l'applicazione in un exe e un modello che prende l'exe e lo esegue sul target (utilizzando InvokeProcess). Se hai bisogno di distribuire la stessa cosa in un altro ambiente, basta usare la stessa posizione di rilascio, viola!

Quello che hai non sembra affatto strano, ha senso gestirlo in quel modo.

Answer 2

La risposta di Daniel è praticamente il modo standard per ottenere un sistema di generazione come TeamBuild per gestire le distribuzioni. È un po 'strano perché stai piegando uno strumento per un altro scopo. Può sicuramente funzionare comunque.

L'altro approccio è ottenere uno strumento di distribuzione puro che si integri con TFS/TeamBuild. La distribuzione in tutti gli ambienti sarebbe naturale, ma poi hai due strumenti da gestire.

Answer 3

So che questa è una risposta tardiva, ma le cose sono cambiate dal 2012. Microsoft ha un Release Management offering ora progettato da zero per abilitare "build once, deploy many". La modifica dei modelli di processo di costruzione è sempre un problema.