Gli errori di distribuzione dovrebbero costituire un errore di compilazione?

5

Il nostro software utilizza il software di distribuzione scritto internamente a causa della complessità del prodotto. Come parte del nostro attuale processo di compilazione del QA (non dev) (utilizzando più software interno), compiliamo il codice, correggiamo i database, distribuiamo il software ed eseguiamo un test del fumo e, in alcuni casi, test dell'interfaccia utente automatizzati, prima della compilazione è passato". Ci stiamo spostando su TFS2010 e stiamo eliminando il processo di compilazione interno e preferirei non dover aggiungere questo processo in build TFS.

Quali processi utilizzi per garantire che la distribuzione abbia successo e riportare gli errori al team di sviluppo? Una build dovrebbe essere classificata come un fallimento in caso di errori di distribuzione / schermo fumogeno o errori di test dell'interfaccia utente automatici?

TFS termina il suo processo di compilazione quando i file vengono posizionati nella cartella di rilascio, quindi contrassegna tale build come OK. Se devo usare la stessa soluzione che abbiamo ora, o TFS build deve essere esteso per eseguire tutte queste attività prima di contrassegnare la compilazione come un successo o dobbiamo avere un meccanismo per contrassegnare la compilazione come fallita dopo che è già riuscita in precedenza .

    
posta DaveShaw 15.07.2011 - 11:23
fonte

3 risposte

3

Penso che anche chi può risolvere il problema, se ci si aspetta che chiunque possa effettuare il check in sia in grado di correggere "errori nella distribuzione", allora dovrebbe fallire la normale build.

Altrimenti dovrei tentare di fare due "build", il primo compila il codice ed esegue i test unitari. La seconda build prende l'output dalla prima build quindi esegue i controlli di distribuzione. In questo modo un normale programmatore che non funziona nel sistema di distribuzione può continuare a funzionare se un altro programmatore ha ampliato l'app in modo tale da richiedere l'aggiornamento degli script di installazione.

Fallire una build che per un problema che poche persone possono adattare tendono a portare a mancate build in errore.

Desiderate che tutti gli sviluppatori smettano di funzionare fino a quando non avranno risolto la build principale, questo avverrà solo se saranno sempre in grado di risolverlo.

    
risposta data 15.07.2011 - 16:39
fonte
1

Se la build non è in grado di generare l'output previsto, è rotto e il motore di generazione deve informare chi ha rotto e chiunque altro debba saperlo.

Nota che, se qualcuno può rompere un processo non rilevante per loro, potresti avere dipendenze più forti di quelle che preferisci nel tuo metodo di compilazione e potresti voler indagare su questo per eliminarle.

    
risposta data 15.07.2011 - 12:03
fonte
0

Qualsiasi errore in tutti i meriti di compilazione o test che contrassegnano la compilazione come un errore.

Qualsiasi errore nella distribuzione può o non può. Dipende da cosa deve essere fatto se si verifica. Di solito ogni errore indica che qualcuno da qualche parte deve intraprendere un'azione (correttiva). Quindi sì, segnerei la costruzione fallita. Immagino che un avviso potrebbe essere ok se si desidera distinguere tra errori di compilazione e di distribuzione, ma penso che sia una questione di semantica.

L'importante è assicurarsi che le notifiche siano inviate e, cosa più importante, leggere. Ad esempio, scarico tutte le mail dal nostro buildserver direttamente nel cestino, a meno che "failure" o "failed" non siano da qualche parte nell'argomento.

    
risposta data 15.07.2011 - 11:43
fonte

Leggi altre domande sui tag