Qual è lo scopo di una macchina di costruzione dedicata?


75

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?


166
"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 [...]" Cosa intendi esattamente? Accedete fisicamente a quella macchina per creare una build?
Vincent Savard,


13
Il vero WTF è Clearcase, che è peggio di tutte le moderne alternative open source. Che lingua (e) è questo progetto e quanto è grande / complessa la build?
pjc50,

7
Stai usando strumenti? Git / SVN e Jenkins / Team City / Octopus / TFS, ecc.? O stai semplicemente accedendo a un altro computer, caricando Visual Studio o cosa hai ... copiando il progetto, caricando, compilando ... Stai usando strumenti professionali o lo stai facendo manualmente?
WernerCD

84
La mia macchina per costruire è da qualche parte nella Carolina del Sud e io sono a Seattle. Ti assicuro che non uso le scale per usarlo. Penso che l'ultima volta che ho avuto accesso fisico a una macchina di compilazione sia stato quando ero il tirocinante responsabile delle macchine di compilazione per i compilatori Microsoft nel 1994, quando si inserirono in un piccolo armadio; ora sono un intero data center da qualche parte. Metti la macchina sulla tua rete; meglio ancora, mettilo nel cloud e fai in modo che qualcun altro se ne occupi.
Eric Lippert

Risposte:


138

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.


3
In realtà non ho più toccato c ++ dal college, ma posso capire l'utilità. Anche se in questo caso, penso che ciò che stiamo effettivamente facendo potrebbe essere molto lontano dallo scopo previsto.
Zibbobz,

21
Per alcuni linguaggi (in particolare C ++) avere una casella dedicata con più potenza di elaborazione può essere utile, dato che è una compilazione relativamente lenta.
Enderland

31
L'integrazione continua significa molto più che avere un solo server di compilazione, ma significa anche che tutti integrano le modifiche degli altri il più frequentemente possibile, per evitare problemi di unione "big bang". Altrimenti, perfetto.
Rob Crawford

Mentre mi piace il potere che un esempio dà al punto qui esposto, penso ancora che l'ultimo paragrafo sia totalmente inutile in questa risposta.
Pierre Arlaud,

3
"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." Non è del tutto vero. Il richiedente ha sottolineato che è molto facile avere un ambiente sporco su una macchina degli sviluppatori. Le librerie incluse e le altre variabili di ambiente possono modificare il risultato di compilazione. Una macchina dedicata dovrebbe avere un ambiente ben documentato per consentire una facile ricostruzione.
TafT

107

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.


37
+ 1 La quantità di volte in cui qualcosa funziona sulla macchina di uno sviluppatore, e non il resto del suo team ...
user2259716

45
Questo. Lo scopo principale di costruire su un'altra macchina è avere build riproducibili ; in particolare eliminando elementi non impegnati, variabili d'ambiente disparate, ecc ... dall'equazione.
Matthieu M.

9
Estendilo: usa un'immagine del contenitore nuova e pulita da cui inizi ogni build. Quindi avere uno script bootstrap per configurare il sistema. Ciò garantisce veramente build riproducibili.
Matthias Kuhn,

9
@MatthiasKuhn: le build riproducibili veramente (byte per byte) richiedono molto di più, cfr: riproducible-builds.org wiki.debian.org/ReproducibleBuilds
ninjalj

1
Inoltre, solo perché la versione Linux del prodotto crea e supera i test sul desktop Linux non significa che verrà costruita la versione Windows o Mac.
Solomon Slow

53

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.


Inoltre, ulteriore resistenza ai virus.
Giosuè,

@Joshua Cosa ti dà quell'idea?
jpmc26

14
@ jpmc26: la macchina di costruzione ottiene molto meno software installato su di essa, ha bisogno di meno punti di accesso remoto e nessuno sta aprendo i browser web su siti Internet casuali su di essa.
Giosuè

19

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.


16

... 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.


5
"Lo dici come se fosse una brutta cosa." Potrebbe essere se hanno il regno libero di installare la spazzatura che vogliono. Se stanno remotando o accedendo fisicamente ad esso, non vedo come ciò possa essere prevenuto.
jpmc26,

7
"Lo dici come se fosse una brutta cosa. Ora hai un server di build comune che tutte le tue build - le tue e quelle degli altri team - sono costruite attraverso. Coerenza di build? Verifica". Questo è l'esatto contrario di una build coerente! Se qualsiasi altro team decide di aggiornare il proprio compilatore o qualsiasi altro strumento, improvvisamente hai a che fare con un ambiente di costruzione completamente diverso. Questo è praticamente uno scenario peggiore (a parte il fatto di non avere una macchina per iniziare).
Voo

1
Concordato di voler avere un processo automatico per la creazione di nuove build, ma allo stesso tempo vuoi anche virtualizzare i tuoi agenti di build per assicurarti che l'ambiente di build sia sotto il tuo controllo. Le VM sono uno strumento straordinario per gli sviluppatori e dovresti sfruttarlo al meglio.
Voo

@Voo Non è quasi uno scenario peggiore, è uno scenario di medio caso. Ciò che attualmente il richiedente ha uno scenario peggiore. (Nota anche che se non riproduci mai build, gli aggiornamenti casuali del compilatore non rappresentano un grosso problema)
user253751

@immibis Hai letto la parte in parentesi subito dopo la parte che hai citato? È uno scenario peggiore se è coinvolto un server di build. Il problema con i bug non riproducibili è che non è possibile eseguire aggiornamenti rapidi se nel frattempo l'intero ambiente di build è cambiato. Questo non è un grosso problema se hai solo una versione rilasciata che è tenuta vicino al trunk, ma in tutti gli altri casi è piuttosto male.
Voo

1

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).


1

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.


4
questo non sembra offrire nulla di sostanziale rispetto ai punti formulati e spiegati nelle precedenti 6 risposte
moscerino
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.