Utilizzo di un modello di processo di compilazione TFS (flusso di lavoro) per la distribuzione

Sto pensando di utilizzare i flussi di lavoro di TFS Build per distribuzioni complesse. Ne abbiamo alcuni che potrebbero aver bisogno di distribuire:

Applicazioni e servizi Web
Banca dati
Rapporti SSRS
Pacchetti SSIS
Chissà cos'altro

Mi piace il fatto di poter fornire al flusso di lavoro alcuni parametri di base come la build da distribuire e la sua esecuzione. Potenzialmente, alcune parti potrebbero richiedere l'approvazione umana e so che anche il flusso di lavoro può gestirlo. Un esempio è che potremmo utilizzare il flusso di lavoro per creare uno script di modifica dai nostri progetti di database di Visual Studio, ma il gruppo DBA vorrà approvare lo script prima che venga eseguito.

Sono interessato a sapere se altri hanno usato "build" per questo in passato e quali problemi sono stati riscontrati.

— John Saunders
fonte

Stiamo usando TFS 2010 per gestire le nostre build / implementazioni. Non ho risposte rapide per te; ma man mano che i problemi sorgono, non esitare a inviarmi un'e-mail e possiamo almeno provare a capirlo.

— Stephen Gross,

Abbiamo usato TFS per attivare le nostre build ma abbiamo usato msbuild per costruire i nostri progetti. Il vantaggio principale è che disponiamo di uno script di build che possiamo modificare mantenendo sotto controllo la versione. La cosa è con i flussi di lavoro, ad esempio: come hai intenzione di costruire una versione precedente del tuo progetto? Con uno script di build ottieni la versione precedente dal controllo del codice sorgente e sei pronto. È anche bello essere in grado di giocherellare con esso e attivare / disattivare diverse opzioni.

Se sei sicuro di avere un ciclo di compilazione fisso, allora probabilmente puoi farcela, altrimenti avere uno script è probabilmente l'opzione più sicura e più felice.

— Carlo Kuip
fonte

I flussi di lavoro sono file .xaml memorizzati nel controllo del codice sorgente. Avrò bisogno di un processo che ramifichi i file .xaml insieme al codice sorgente. Senza dubbio si ramificano i file msbuild insieme al sorgente.

— John Saunders,

@JohnSaunders sì, ramifichiamo i nostri script di build. È bello che la configurazione del tuo flusso di lavoro sia memorizzata in un file xml ma che influenza ha la modifica della configurazione sugli elementi che si trovano in una versione diversa del tuo flusso di lavoro (elementi di lavoro, attività, ecc. All'interno del tuo progetto rientrano nello stesso flusso di lavoro, giusto? ) È qui che vedo un rischio, cambiando il comportamento di come TFS gestisce il tuo progetto al volo.

— Carlo Kuip,

Non so cosa intendi. La modifica del modello del processo di compilazione non cambierà gli elementi di lavoro. Cosa intendi con "elementi che si trovano in una versione diversa del tuo flusso di lavoro"?

— John Saunders,

Il modello di processo che si applica durante la creazione di un progetto TFS sta creando un flusso di lavoro. Ciò significa che se si crea un elemento di lavoro, questo è collegato alle varie fasi di tale flusso di lavoro. Il tuo processo di compilazione sarà un'estensione di quel flusso di lavoro o è separato?

— Carlo Kuip,

Spiacenti, stai confondendo un modello di processo e un modello di processo di generazione. Microsoft ha scelto male i termini. Inoltre, il modello di processo che usi durante la creazione di un progetto di gruppo non crea alcun flusso di lavoro di cui sono a conoscenza.

— John Saunders,