Nella mia azienda stiamo attualmente ricercando varie strategie per accelerare le nostre build CI. Abbiamo profilato le nostre build e determinato che siamo vincolati da un collo di bottiglia di I/O. Abbiamo parecchie opzioni per affrontarlo nel prossimo futuro (~ 1-2 mesi), ma mi piacerebbe vedere un miglioramento ora.È ragionevole usare un ramdisk su un server di build?
Ho proposto di utilizzare un ramdisk come posizione di checkout e buildfile. Gli output ed i log di build verrebbero ovviamente memorizzati sul disco fisico.
È una cosa sensata da fare o ci sono degli svantaggi significativi in questo approccio? Non sto cercando risposte che riguardino il lato hardware delle cose, ma piuttosto che l'interazione tra sistemi di compilazione comuni (ad es. MSBuild) e un ramdisk causeranno problemi e se ci sono altri rischi di cui devo essere a conoscenza.
Una semplice nota: presumo che stiate parlando di build notturne qui? nel qual caso, ovviamente, è necessario spremere il massimo di build da zero e test. Se fossero build giornalieri, suggerisco di mantenere il tempo di costruzione intorno a un massimo di 5 Mn in modo che gli sviluppatori possano ottenere un rapido feedback su potenziali problemi a ogni commit: in questo caso, è la maggior parte del tempo utile per fare la compilazione * incremental *, cioè, basta fare un aggiornamento svn (hg/git/etc.), e usare Make (o Ant, Nant, ecc.) per ri -compila cosa è cambiato. Con un buon Makefile scritto, potrebbe anche velocizzare le cose in modo drammatico. Solo il mio 0,02 € :-) –
Sto parlando di CI qui (costruire dopo ogni commit). Approfittiamo già di build incrementali per questo, ma grazie. –
@Christophe Muller, facendo una dichiarazione generale che una build dovrebbe essere "massimo di 5 Mn" è davvero ridicola senza conoscere l'ambiente, le dimensioni e i requisiti della build. Abbiamo un prodotto che gira su un server CI e costruisce in meno di due minuti, compresi compilazione e packaging. Abbiamo un altro prodotto che include diverse soluzioni .NET, diversi servizi Windows nativi, più progetti Adobe Flex, test unitari, copertura del codice, packaging e distribuzione automatizzata su un rack di test. L'intero processo (non tutto viene eseguito ad ogni check-in) è di oltre due ore e mezzo * ore *. –