Qual è lo scopo di una macchina di compilazione dedicata?

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

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

Generalmente è possibile accedere ai server di creazione da più utenti o team contemporaneamente, utilizzando una GUI Web eseguita in un browser.

Nel mondo Java uno dei server di build più utilizzati è Jenkins. Jenkins funziona perfettamente anche con le versioni C ++ (visto che sembra che tu stia usando quelle due lingue). Jenkins si chiama server di automazione, dal momento che può eseguire tutti i tipi di attività che non devono essere correlate alla programmazione e alla creazione.

Oltre alla risposta di Traubenfuchs, hai suggerito un altro motivo per una macchina da costruzione nella tua domanda.

Solo perché il software si basa sulla tua macchina, non significa che verrà costruita su quella di chiunque altro. Potresti contare su alcuni file casuali che si trovano sulla tua macchina (e potrebbero non essere nemmeno sotto controllo di versione). Potresti contare su qualche applicazione o libreria dimenticata richiamata da uno script di compilazione oscuro.

Se hai una macchina di sviluppo dedicata, dovresti sapere cosa è installata su di essa. Questo dovrebbe essere ben documentato. Se è necessario ricostruire il software, forse anni dopo, dovrebbe essere necessario solo creare una nuova macchina di compilazione con gli elementi documentati installati su di essa.

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

Non è chiaro quale piattaforma / lingua si stia utilizzando, ma idealmente si dovrebbe avere un server di compilazione che estrae direttamente dal controllo del codice sorgente. Cioè, quando è richiesta una build, recupererà l'origine da una data versione del repository e la compilerà automaticamente. Ciò richiede l'uso di strumenti di compilazione automatizzati per scrivere la build. Se non hai questo, dovrebbe essere il punto 1.

Tieni presente che non c'è niente di sbagliato nel costruire localmente per lo sviluppo. Dovresti sicuramente lavorare sui test unitari eseguiti localmente, sull'analisi della qualità del codice e sull'elaborazione degli script di compilazione. Altrimenti perderai un sacco di tempo. L'output del build server è per tutto ciò che si desidera passare alla produzione. Tutte le attività di controllo qualità come l'integrazione e il test di accettazione devono essere eseguite solo con build dal build server.

Le altre risposte hanno correttamente notato che è necessario automatizzare la build, il che significa che non è necessario andare in un altro ufficio. Tuttavia, permettimi di proporre un certo numero di passaggi da eseguire per migliorare il processo di creazione:

• In primo luogo, imposta l'accesso remoto al server di build! Se costruisci manualmente digitando il comando "make", questo significa che non devi più camminare 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 build simile, prendi in uso un sistema di compilazione simile.
• 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? se no, sarebbe un ulteriore passaggio) e le costruisce. Raccomando Jenkins. Configura Jenkins per eseguire anche i tuoi test di unità e test di integrazione a livello di sistema (ne hai entrambi, giusto? Se no, crearli a partire dai test unitari e quindi terminare con i test di integrazione a livello di sistema).
• In terzo luogo, se ritieni che la condivisione della stessa macchina con altri team sia problematica (ad esempio se hai opinioni diverse su quale sistema operativo e quale versione e bittosità dovresti utilizzare), considera l'utilizzo della virtualizzazione. Un buon server oggi può eseguire un numero enorme di macchine virtuali. Forse potresti impostare una macchina a 32 bit e una macchina a 64 bit in modo da sapere che la build funziona su entrambe le architetture.
• Infine, potrebbe non essere necessario: se è assolutamente necessario disporre di una macchina dedicata, ad esempio se le prestazioni delle applicazioni sono di grande importanza e altre esecuzioni / test in esecuzione contemporaneamente influenzano troppo i risultati, installare un programma dedicato server hardware che 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 della CPU.

Considererei una macchina condivisa molto meglio delle versioni manuali. Il mio progetto attuale utilizza una macchina virtuale ora, 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 virtuali di cui i test delle prestazioni richiedono 17.

... instead of getting an actual machine in our office to use, we're having to share a single machine with several other groups ...

Lo dici come se fosse una brutta cosa

Ora hai un server di compilazione comune a cui sono costruite tutte le tue build, la tua e le altre squadre. Coerenza di costruzione? Dai un'occhiata.

... the hassle of having to leave my office with all the necessary information and then walk down a flight of stairs to another office just to perform a simple build is making me wonder why I ever proposed this in the first place.

Stai ancora eseguendo la manualmente e non va bene.

È necessario un processo del server a cui si inoltrano / accodano richieste per le build da eseguire per conto dell'utente e che tale processo rispedisca i risultati.

Oltre alle altre risposte pertinenti, sembra che tu stia eseguendo le tue build direttamente sulla macchina in questione.

Per un sistema di build affidabile, specialmente quando si condivide la macchina di compilazione con altri utenti, è normale eseguire le build in una macchina virtuale. Ciò garantisce che altri utenti non possano modificare il comportamento delle build installando le proprie versioni di applicazioni o librerie da cui dipende il codice. Un grande vantaggio è che la VM può essere facilmente salvata e può anche essere facilmente clonata su qualsiasi altro PC (incluso il tuo computer di sviluppo).

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

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

Oltre a rendere tutto più ripetibile e affidabile e ad assicurare che il repository non sia pieno di spazzatura rotta con problemi di dipendenza in agguato, semplifica la vita degli sviluppatori perché tutto ciò che devono fare per far funzionare la build sulla loro macchina è per copiare qualsiasi cosa si stia facendo sul computer di costruzione.