ReBitting

Non so a voi ma a me piace proprio così:

Se vi piace, potete scaricare il file di configurazione da quì.

L’autore di questo tema potete trovarlo quì.

• Ad ogni Checki-in.
• Dopo un numero preciso di check-ins.
• Dopo un intervallo di tempo.
• Dopo un numero preciso di check-ins o dopo un'intervallo di tempo.
• Ad una data/orario prefissato.

Ad ogni Checki-in:

PRO:

• Ultime modifiche subito disponibili per il Team di test.

CONTRO:

• In un grosso progetto rischiamo di avere una frequenza di build troppo elevata, sovraccaricando il server di Team Build.

Dopo un numero preciso di check-ins:

PRO:

• Il server di build non viene sovraccaricato e abbiamo una build abbastanza aggiornata.

CONTRO:

• L'ultimo check-in potrebbe esser fatto a fine giornata e il team di test potrebbe trovare la versione corrente solamente il giorno successivo.

Dopo un intervallo di tempo:

PRO:

• Il server di build non viene sovraccaricato e abbiamo una build abbastanza aggiornata.

CONTRO:

• Ad ogni build abbiamo un numero variabile di codice aggiornato. Potremmo ritrovarci build con una modifica e build con 100 modifiche, dove potremmo aver problemi a capire in quale parte del codice abbiamo inserito un bug.

Dopo un numero preciso di check-ins o dopo un'intervallo di tempo:

PRO:

• E' una buona alternativa dai due metodi dai quali deriva.
• Crea un build dopo un certo numero di check-ins o dopo un certo intervallo di tempo.
• Il server di build non viene sovraccaricato e abbiamo una build abbastanza aggiornata.

CONTRO:

• Se settato in maniera non corretta può creare più problemi che altro. Bisognerebbe settare un numero minimo di check-ins prima di fare una build se ci orientiamo sulle modifiche.

Ad una data/orario prefissato:

PRO:

• Crea un build in specifici giorni della settimana ad un orario.
• Il server di build non viene per nulla sovraccaricato.

CONTRO:

• La build ottenuta non sarà allineata al codice nel source control prima del giorno-ora impostati.

Tutte queste strategie di Build possono essere intrecciate con delle policy di check-in per non sovraccaricare il server di build.

Ad esempio potremmo accettare il codice in check-in solo se i test ritornano un esito positivo e solo se il codice scritto può esser associato ad un Work Item.

Altre strategie di building, come creare una build ad ogni ora, può essere implementata in due maniere; o utilizzando Microsoft Windows® Task Scheduler:

1. Eseguire il TfsBuild così:
   TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>>
   
2. Inserire il comando in un file di batch, specificando il percorso completo del TfsBuild
   "<driver>\Program Files\Microsoft Visual Studio 9\Common7\IDE\TFSBuild" start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>>
   
3. Creare un task apposito.

potremmo anche definire una build per ogni ora del giorno; sarebbe cmq un peso da gestire.

Cancellare un Team Project può non essere così immediato.

Per poter cancellarlo andate nella directory:

<drive >\Program Files\Microsoft Visual Studio 9\Common7\IDE

e scrivete il seguente comando:

TfsDeleteProject /server:myteamserver.benday.com “Project Name“

Per un elenco completo delle opzioni leggete quì.

In un post del forum Microsoft è stato chiesto come fare una build di un progetto su Team System, compilando solamente i progetti modificati e non tutta la solution.
Il post è un pò vecchiotto (29 agosto 2007) ma credo ancora valido
La riposta è la seguente:

Se siete interessati al thread, cliccate quì.

Edit 15-09 14:40:
Un altro interessante link: http://blogs.msdn.com/aaronhallberg/archive/2008/02/12/team-build-2008-property-reference.aspx

Edit 16-09 12:31:
si può ottenere lo stesso risultato in TFS 2005.
Nel seguente link è spiegato come fare:
http://blogs.microsoft.co.il/blogs/maordavid/archive/2008/06/12/configure-team-foundation-build-for-an-incremental-build.aspx