- 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:
- Eseguire il TfsBuild così:
TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>>
- 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>>
- Creare un task apposito.
potremmo anche definire una build per ogni ora del giorno; sarebbe cmq un peso da gestire.