Qual è lo scopo di una macchina di costruzione dedicata?

A causa di una serie di circostanze che hanno portato a un cattivo ciclo di implementazione nell'ultima build, ho fatto una campagna nel nostro ufficio per eseguire tutte le future implementazioni con una macchina di build dedicata e il mio capo ha accettato questa proposta.

Tuttavia, invece di utilizzare una macchina reale nel nostro ufficio, dobbiamo condividere una macchina singola con molti altri gruppi - e la seccatura di dover lasciare il mio ufficio con tutte le informazioni necessarie e poi scendere una rampa di scale in un altro ufficio solo eseguire una semplice build mi sta chiedendo perché l'ho mai proposto in primo luogo.

L'idea di avere una macchina di compilazione separata era, in origine, quella di separare il mio codice scritto localmente dal codice di molti altri sviluppatori e di separare dalla distribuzione tutti i file dirottati che avevo sulla mia macchina. È stato anche per risolvere una crescente preoccupazione che ho avuto con il nostro sistema di gestione dei file ClearCase, che spesso si rifiuta di farmi distribuire determinate attività di compilazione a meno che non abbia incluso anche un'altra attività per la quale "ha dipendenze".

Ora che sto effettivamente andando avanti con questo processo, mi chiedo se ho frainteso l'intero scopo dell'utilizzo di una macchina di generazione - e dal momento che stiamo usando questa macchina solo per la distribuzione del codice nei nostri ambienti di Test, Staging e Produzione, e non per le nostre distribuzioni di test personali per gli sviluppatori, non sono sicuro che serva a nessuno scopo.

Quindi, qual è la vera ragione per usare una macchina per costruire, e mi sono persino avvicinato ad usarla correttamente?

Normalmente non avresti solo una macchina di compilazione dedicata, ma esegui anche un server di compilazione su quella macchina dedicata. Una macchina di costruzione dedicata offre semplicemente il vantaggio di non bloccare mai il lavoro di uno sviluppatore e di distribuirla da una macchina centralizzata.

Un server di build offre molto di più. Un server di compilazione consente CI (integrazione continua), il che significa che si baserà automaticamente su ogni push sul VCS (come git), potrebbe anche eseguire test unitari se li hai e consentire la "distribuzione con un clic". I server di build possono avvisarti per posta se build o test falliscono. Offrono dati storici e tendenze su ciò che è accaduto.

Generalmente i server di build sono accessibili da più utenti o team contemporaneamente, utilizzando una GUI Web che viene eseguita in un browser.

Nel mondo Java uno dei server di build più utilizzati è Jenkins. Jenkins funziona perfettamente anche con build C ++ (dal momento che sembri usare quei due linguaggi). Jenkins si definisce server di automazione, poiché può eseguire tutti i tipi di attività che non devono essere correlate alla programmazione e alla costruzione.

Oltre alla risposta di Traubenfuchs, hai accennato a un'altra ragione per una macchina da costruzione nella tua domanda.

Solo perché il software si basa sul tuo computer, ciò non significa che si baserà su quello di chiunque altro. Potresti fare affidamento su alcuni file casuali che si trovano sul tuo computer (e potrebbero anche non essere sotto il controllo della versione). Potresti fare affidamento su un'applicazione o libreria dimenticata che viene richiamata da uno script di build oscuro.

Se hai una macchina di compilazione dedicata, dovresti sapere cosa è installato su di essa. Questo dovrebbe essere ben documentato. Se c'è mai la necessità di ricostruire il software, forse anni dopo, dovrebbe essere necessario solo creare una nuova macchina di compilazione con le cose documentate installate su di esso.

Il motivo principale per avere una macchina di compilazione dedicata è ottenere build coerenti indipendentemente da chi sta eseguendo la build. Le stazioni di lavoro degli sviluppatori sono raramente (leggi: mai) identiche. È difficile sapere che ogni build utilizza le stesse versioni esatte di dipendenze e compilatori, ecc. Uno dei problemi peggiori con le build di workstation dev è che gli sviluppatori possono creare dal codice che non è controllato nel controllo di versione.

Non è chiaro quale piattaforma / lingua stai usando, ma idealmente dovresti avere un server di build che tira direttamente dal controllo del codice sorgente. Cioè, quando è richiesta una build, recupererà l'origine da una determinata versione del repository e la compilerà automaticamente. Ciò richiede l'uso di strumenti di compilazione automatizzati per eseguire lo script della build. Se non lo hai, dovrebbe essere il passaggio 1.

Tieni presente che non c'è nulla di sbagliato nella costruzione locale per lo sviluppo. Dovresti assolutamente lavorare localmente eseguendo unit test, analisi della qualità del codice e per affinare gli script di build. Altrimenti perderai molto tempo. L'output del server di build è per tutto ciò che si desidera spostare potenzialmente in produzione. Tutte le attività di controllo qualità come test di integrazione e accettazione devono essere eseguite solo con build dal server di build.

Le altre risposte hanno giustamente notato che dovresti automatizzare la build, il che significa che non è necessario andare in un altro ufficio. Tuttavia, lasciami proporre un certo numero di passaggi che potresti intraprendere per migliorare il tuo processo di compilazione:

• Innanzitutto, imposta l'accesso remoto al server di compilazione! Se costruisci manualmente digitando il comando "make", ciò significa che non devi più andare in un altro ufficio per digitare "make", puoi semplicemente SSH nel server di build e digitare "make". Se non usi ancora make o un sistema di compilazione simile, utilizza un tale sistema di build.
• In secondo luogo, installa un ambiente di integrazione continua che estrae automaticamente le ultime modifiche dal sistema di controllo della versione (hai un sistema di controllo della versione, giusto? In caso contrario, sarebbe un passaggio aggiuntivo) e le costruisce. Consiglio Jenkins. Configura Jenkins per eseguire anche i test unitari e i test di integrazione a livello di sistema (hai entrambi, giusto? In caso contrario, creali partendo dai test unitari e finendo poi con i test di integrazione a livello di sistema).
• In terzo luogo, se ritieni che condividere la stessa macchina con altri team sia problematico (ad esempio se hai opinioni diverse su quale sistema operativo e quale versione e funzionalità dovresti usare), prendi in considerazione l'uso della virtualizzazione. Un buon server oggi può eseguire un numero enorme di macchine virtuali. Forse potresti installare una macchina a 32 bit e una macchina a 64 bit in modo da sapere che la build funziona su entrambe le architetture.
• Infine, ciò potrebbe non essere necessario: se è assolutamente necessario disporre di una macchina dedicata, ad esempio se le prestazioni dell'applicazione sono di grande importanza e altre build / test eseguiti contemporaneamente influiscono troppo sui risultati, installare un server hardware dedicato rispetto a solo tu usi. Tuttavia, su server recenti che possono avere fino a 40 core di CPU virtuali o anche di più, è relativamente semplice creare alcune macchine virtuali che non condividono l'accesso agli stessi core di CPU.

Considererei una macchina condivisa molto meglio delle build manuali. Il mio attuale progetto utilizza ora una macchina virtuale, ma a causa della necessità di test delle prestazioni di integrazione a livello di sistema, ci stiamo spostando su un server dedicato con 40 core di CPU virtuale di cui i test delle prestazioni richiedono 17.

... invece di utilizzare una macchina reale nel nostro ufficio, dobbiamo condividere una macchina singola con molti altri gruppi ...

Lo dici come se fosse una brutta cosa.

Ora hai un server di build comune attraverso il quale vengono costruite tutte le tue build, le tue e quelle degli altri team. Coerenza di costruzione? Dai un'occhiata.

... la seccatura di dover lasciare il mio ufficio con tutte le informazioni necessarie e poi scendere una rampa di scale per un altro ufficio solo per eseguire una semplice costruzione mi fa chiedermi perché l'ho mai proposto in primo luogo.

Stai ancora eseguendo la build manualmente e non va bene.

È necessario un processo server al quale si inoltrano / accodano richieste per l'esecuzione di build per conto dell'utente e che tale processo restituisca i risultati.

Oltre ad altre risposte pertinenti, sembra anche che tu stia eseguendo le tue build direttamente sul computer in questione.

Per un sistema di compilazione affidabile, in particolare quando si condivide la build machine con altri utenti, è normale eseguire le build all'interno di una macchina virtuale. Ciò garantisce che altri utenti non possano modificare il comportamento delle build installando le proprie versioni di applicazioni o librerie dalle quali dipende il codice. Un grande vantaggio di ciò è che è possibile eseguire facilmente il backup della VM e può essere facilmente clonata su qualsiasi altro PC (incluso il proprio computer di sviluppo).

Fornisce una posizione centralizzata e neutrale per eseguire build, indipendentemente dall'IDE, dal sistema operativo e dalle configurazioni della libreria dei singoli sviluppatori.

Con una macchina di compilazione dedicata, puoi farla ricostruire ogni volta che c'è un push del codice nel repository. Quando qualcuno interrompe la generazione, il processo può immediatamente inviare un avviso in modo che il problema possa essere risolto immediatamente.

Oltre a rendere tutto più ripetibile e affidabile e garantire che il repository non sia pieno di immondizia rotta con problemi di dipendenza in agguato, semplifica la vita degli sviluppatori perché tutto ciò che devono fare per far funzionare la build sul proprio computer è copiare qualunque cosa viene eseguito sulla macchina di compilazione.