Come possiamo migliorare il nostro processo di compilazione?

3

La società in cui lavoro ha un (a mio avviso) processo di costruzione lento. Utilizziamo TFS e il controllo del codice richiede diverse ore. Funziona così:

(Supponendo che la modifica sia stata apportata e che la revisione del codice sia stata approvata)

Innanzitutto, apporti le modifiche e invialo per un passaggio di approvazione tramite un pulsante in Visual Studio. Questo costruisce l'intera soluzione dello studio visivo e gestisce un sottoinsieme di test che consideriamo fondamentali per il progetto. Queste build vengono eseguite in parallelo per l'efficienza. Se questo succede, il passo successivo viene automaticamente avviato. Se fallisce, ricevi un'email di compilazione che dice quali test hanno fallito e per quale motivo, a quel punto devi ricominciare.

[Questo primo passo richiede diverse ore per completare]

In secondo luogo, lo stesso set di test viene eseguito come prima con la tua modifica, tranne che invece di queste build eseguite in parallelo, sono serializzate. Se la compilazione ha esito positivo, le modifiche vengono verificate nella "linea principale". (Usavamo i rami, ma non lo facciamo più). Se questo non riesce, ricevi un'email di compilazione che dice quali test hanno avuto esito negativo e per quale motivo, e devi ricominciare da capo.

[Questo secondo passo richiede molte più ore per completare]

Terzo, (ricorda che il codice è già stato archiviato a questo punto), viene eseguita una build più completa che esegue tutti i test invece di un solo sottoinsieme. Poiché questa build impiega così tanto tempo, i changeset vengono caricati in batch e, come in passato, se la compilazione fallisce, ricevi un'email che dice quali test hanno fallito. Sfortunatamente, può essere difficile capire se il tuo cambiamento è stato il colpevole.

[Questo terzo passaggio richiede molte più ore per completare]

Abbiamo il concetto di un "test intermittente". Se un test fallisce, lo eseguiamo fino a due volte per vedere se passa. Sappiamo che questo è male, ma non abbiamo fatto lo sforzo di eliminare questo tipo di test.

Inoltre, questo processo è stato recentemente interrotto da problemi con test che hanno bloccato troppe risorse sulle macchine di compilazione, o persone che ignorano il processo e controllano direttamente il codice, che interrompe il primo passo.

Per riferimento, la dimensione del progetto è nell'ordine di un milione di righe di codice. Non mi aspetto che i build impieghino alcuni minuti, ma dopo aver letto delle persone che fanno un'integrazione continua e come dovrebbero impiegare al massimo 10 minuti, dovresti essere in grado di eseguire immediatamente tutti i tuoi test, ecc. Sto diventando molto scoraggiato lo stato del nostro processo.

Come potremmo migliorare il nostro processo di costruzione in modo che ci sia un tempo di risposta più breve tra la preparazione di una modifica e l'accesso alla linea principale?

    
posta Michael Hagar 02.11.2016 - 20:37
fonte

1 risposta

4

Alcune cose che posso vedere subito (anche se non ho idea di quanto siano raggiungibili):

  • aggiungi il profilo ai tuoi test di unità. capire quali durano più a lungo e farli lavorare più velocemente.
  • rifatta il tuo progetto in progetti più piccoli che ognuno può eseguire separatamente. Un singolo progetto con milioni di LoC è davvero difficile da mantenere, ed è probabilmente meglio se dividi il tuo progetto in blocchi più o meno separati. Sia che tu scelga la separazione orizzontale o verticale o una combinazione dipende dal tuo progetto.
  • Fai qualcosa per i tuoi test intermittenti. Test falliti significa che il tuo software è rotto, semplice come quello. Per lo meno, controlla quali test falliscono per 3 volte di seguito e fai uno sforzo per risolverli.
  • se i tuoi sviluppatori non stanno già utilizzando apparecchiature di fascia alta, investi in attrezzature veloci per i tuoi sviluppatori e la tua macchina di costruzione (o le macchine, più su questo in un momento). Se si confronta il prezzo dell'hardware con quello di un buon sviluppatore, è quasi sempre più economico buttare un hardware in più sul problema piuttosto che spendere più tempo per il problema. a circa 100K all'anno e 2K ore per dev, stai guardando a 50 USD / h. Se spendi 1500 USD per dev su hardware di fascia alta (1 SS M.2 SSD, CPU Intel hexacore, 64 GB di RAM come un ballpark *) risparmia ogni dev una ora alla settimana in tempi di compilazione e test più veloci, sei ancora risparmiando mille dollari per dev un anno.
  • Dividi i tuoi test batch in blocchi. Ottieni 2, 3 o più macchine di compilazione (di nuovo, rendili veloci), dividi i tuoi test unitari in gruppi approssimativamente uguali e lascia che ogni macchina esegua il proprio gruppo. se eseguendo tutti i test delle unità hai impiegato 5 ore prima, dividerli in 5 gruppi e eseguirli su macchine separate significa che stai osservando una build che dovrebbe richiedere solo 1 ora.

* 1 SS M.2 SSD costa 329 USD. 6 core Intel i7 6850K con chipset X99 costa 617 USD. 32 GB di RAM costano 200 USD. La scheda madre X99 costa circa 2-300 USD. per circa 14-1500 USD, hai una macchina che può forzare la sua forza attraverso una build.

    
risposta data 02.11.2016 - 23:47
fonte

Leggi altre domande sui tag