Qual è il punto di un "Build Server"?

Question

Non ho lavorato per organizzazioni molto grandi e non ho mai lavorato per una società con un "Build Server".

Qual è il loro scopo? Perché gli sviluppatori non costruiscono il progetto sulle loro macchine locali, o no? Alcuni progetti sono così grandi che sono necessarie macchine più potenti per costruirlo in un ragionevole lasso di tempo?

L'unico punto in cui vedo utile un server di sviluppo è l'integrazione continua con il server di build che crea costantemente ciò che è impegnato nel repository. È che non ho appena lavorato a progetti abbastanza grandi?

Qualcuno, per favore chiariscimi: qual è lo scopo di un server di build?

Answer 1

Il motivo addotto è in realtà un enorme vantaggio. Le build che vanno al QA dovrebbero provenire solo da un sistema che costruisce solo dal repository. In questo modo i pacchetti di costruzione sono riproducibili e tracciabili. Gli sviluppatori che costruiscono manualmente il codice per qualsiasi cosa tranne il proprio test sono pericolosi. Troppo rischio di roba non sempre ha registrato, essendo fuori aggiornati con le modifiche di altre persone, ecc ecc

Joel Spolsky on this matter.

Answer 2

Ne usiamo uno in modo tale che sappiamo che le caselle di produzione/test hanno le stesse librerie e le stesse versioni di quelle librerie installate come quelle disponibili sul server di compilazione.

Answer 3

Il build server viene utilizzato per creare il codice di tutti quando viene archiviato. Il codice può essere compilato localmente, ma molto probabilmente non tutte le modifiche verranno apportate da tutti gli altri in qualsiasi momento.

Answer 4

Per una qualità costante e per ottenere la build 'fuori dalla macchina' per individuare gli errori dell'ambiente e in modo che tutti i file che si dimenticano di effettuare il check-in al controllo sorgente vengano visualizzati come errori di compilazione.

ho anche usarlo per creare programmi di installazione in quanto questi prendono un sacco di tempo per fare sul desktop con la firma del codice, ecc

Answer 5

Si tratta di gestione e di prova per noi. Con un server di build sappiamo sempre che possiamo costruire la nostra linea principale "trunk" dal controllo di versione. Possiamo creare un'installazione master con un clic e pubblicarla sul Web. Possiamo eseguire tutti i nostri test unitari ogni volta che viene effettuato il check in per assicurarsi che funzioni. Raccogliendo tutte queste attività in una singola macchina, è più facile farlo correttamente.

Answer 6

Un server di build ottiene una sorta di seconda opinione del codice. Quando lo controlli, il codice è selezionato. Se funziona, il codice ha una qualità minima.

Answer 7

È necessario disporre di un ambiente "pulito" privo di artefatti delle versioni precedenti (e modifiche alla configurazione) al fine di garantire che le build e i test funzionino e non dipendano dalle risorse. Un modo efficace per isolare è creare un server di compilazione separato.

Answer 8

Un server di build è un concetto distinto per un server di integrazione continua. Il server CI esiste per creare i tuoi progetti quando vengono apportate modifiche. Al contrario esiste un server Build per costruire il progetto (tipicamente una versione, contro una revisione con tag) in un ambiente pulito. Assicura che nessun hacking dello sviluppatore, modifiche, versioni non approvate di config/artefatto o codice non eseguito lo faccia nel codice rilasciato.

Answer 9

Queste macchine vengono utilizzate per diversi motivi, tutte che cercano di fornire un prodotto superiore.

Un uso è simulare una tipica configurazione dell'utente finale.Il prodotto potrebbe funzionare sul tuo computer, con tutti gli strumenti di sviluppo e le librerie impostati, ma l'utente finale probabilmente non avrà la tua stessa configurazione. Del resto, altri sviluppatori non avranno la stessa identica configurazione. Se hai un percorso hardcoded da qualche parte nel tuo codice, probabilmente funzionerà sul tuo computer, ma quando Dev El O'per prova a creare lo stesso codice, non funzionerà.

Inoltre possono essere utilizzati per monitorare chi ha rotto il prodotto per ultimo, con quale aggiornamento e dove il prodotto è regredito a. Ogni volta che il nuovo codice viene archiviato, il build server lo crea e, se fallisce, è chiaro che qualcosa è sbagliato e l'utente che ha commesso l'ultima volta è in errore.

Answer 10

Sono d'accordo con le risposte finora in merito a stabilità, tracciabilità e riproducibilità. (Un sacco di 'ity, giusto?). Avendo SEMPRE lavorato per grandi aziende (Health Care, Finance) con server di produzione MANY, aggiungo che riguarda anche la sicurezza. Hai mai visto il film Office Space? Se uno sviluppatore scontento costruisce un'applicazione bancaria sulla sua macchina locale e nessun altro la guarda o la verifica ... BOOM. Superman III.

Answer 11

Inoltre, ricorda che i linguaggi di basso livello richiedono molto più tempo rispetto ai linguaggi di alto livello. È facile pensare "Be ', il mio progetto .Net viene compilato in un paio di secondi! Qual è il problema?" Qualche tempo fa ho dovuto fare un po 'di codice C e ho dimenticato quanto tempo ci vuole per compilare.

Answer 12

Hai ragione che gli sviluppatori potrebbero costruire sulle proprie macchine.

Ma queste sono alcune delle cose che il nostro server di build di noi acquista, e siamo a malapena sofisticati produttori di costruire:

• problemi di controllo di versione (alcuni sono stati menzionati nelle risposte precedenti)
• efficienza. Gli sviluppatori non devono fermarsi per creare build a livello locale. Possono dare il via al server e andare al prossimo compito. Se le build sono grandi, allora è ancora più tempo che la macchina dello sviluppatore non è occupata. Per chi fa integrazione continua e test automatici, ancora meglio.
• Centralizzazione. La nostra macchina di compilazione ha script che creano la build, la distribuiscono agli ambienti UAT e persino alla gestione temporanea della produzione. Mantenerli in un posto riduce il fastidio di tenerli sincronizzati.
• Sicurezza. Non facciamo molto speciale qui, ma sono sicuro che un amministratore di sistema può fare in modo che gli strumenti di migrazione di produzione siano accessibili solo su un server di build da parte di determinate entità autorizzate.

Answer 13

forse sono l'unico ...

penso tutti sono d'accordo che si dovrebbe

• utilizzare un repository di file
• fare costruisce dal repository (e in un ambiente pulito ambiente)
• utilizzare un server di prova in continuo (ad es. cruise control) per vedere se qualcosa è rotto dopo il "correzioni"

Ma a nessuno importa delle versioni costruite automaticamente. Quando qualcosa è stato rotto in una build automatica, ma non lo è più, a chi importa? E 'un lavoro in corso. Qualcuno l'ha riparato.

Quando si desidera eseguire una versione di rilascio, si esegue una generazione dal repository.E sono abbastanza sicuro di voler taggare la versione nel repository al del tempo e non ogni sei ore quando il server funziona.

Quindi, forse un "server di build" è solo un termine improprio ed è in realtà un "server di test continuo". Altrimenti sembra praticamente inutile.

Answer 14

Qual è il loro scopo?
Prendere il carico delle macchine sviluppatore, fornire un ambiente stabile e riproducibile per le build.

Perché gli sviluppatori non costruiscono il progetto sulle loro macchine locali o no?
Perché con un software complesso, molte cose possono andare storte quando si "compila". problemi che ho effettivamente riscontrato:

• controlli di dipendenza incompleti di tipi diversi, con conseguente binari non aggiornati.
• Pubblica comandi che non funzionano in modo silenzioso, il messaggio di errore nel registro ignorato.
• Build comprendente sorgenti locali non ancora impegnate per il controllo del codice sorgente (fortunatamente, nessuna finestra di messaggio "maledettamente clienti" ancora ..).
• Quando si tenta di evitare il problema sopra costruendo da un'altra cartella, alcuni file vengono prelevati dalla cartella sbagliata.
cartella
• di destinazione in cui vengono aggregati i binari contiene ulteriori file di sviluppo stantii che non shoulkd essere inclusi nel rilascio

Abbiamo un aumento sorprendente stabilità dal momento che tutte le emissioni pubbliche iniziano con un get dal controllo di origine su una cartella vuota . Prima c'erano molti "problemi divertenti" che "sono andati via quando Joe mi ha dato una nuova DLL".

Alcuni progetti sono così grandi che sono necessarie macchine più potenti per costruirlo in un ragionevole lasso di tempo?

Cos'è "ragionevole"? Se eseguo una compilazione batch sul mio computer locale, ci sono molte cose che non posso fare. Piuttosto che pagare gli sviluppatori per le build da completare, paga IT per acquistare già una vera macchina da costruzione.

È che non ho appena lavorato a progetti abbastanza grandi?

La dimensione è sicuramente un fattore, ma non l'unico.

Answer 15

I server di creazione sono importanti per diversi motivi.

• isolano l'ambiente Il locale Code Monkey developer dice: "Compila il mia macchina" quando non viene compilato sul vostro. Questo può significare check-in fuori sincrono o potrebbe significare che manca una libreria dipendente. Jar inferno non è così male come .dll hell; in entrambi i casi, l'uso di un server di build è un'assicurazione economica che le tue build non falliranno misteriosamente o impaccheranno erroneamente le librerie sbagliate.

• Concentrano le attività associate alle build. Ciò include l'aggiornamento del tag build, la creazione di qualsiasi pacchetto di distribuzione, l'esecuzione di test automatici, la creazione e la distribuzione di report di build. L'automazione è la chiave.

• Coordinano lo sviluppo (distribuito). Il caso standard è dove più sviluppatori stanno lavorando sulla stessa base di codice. Il sistema di controllo delle versioni è il cuore di questo tipo di sviluppo distribuito, ma a seconda dello strumento, gli sviluppatori potrebbero non interagire molto con il codice di entrambi. Invece di costringere gli sviluppatori a rischiare build inadeguate o preoccuparsi di unire eccessivamente il codice, progettare il processo di compilazione in cui la build automatizzata può vedere il codice appropriato ed elaborare gli artefatti di build in un modo prevedibile. In questo modo, quando uno sviluppatore commette qualcosa con un problema, come non controllare una nuova dipendenza da file, può essere avvisato rapidamente. Facendo questo in un'area progressiva, ti segnaliamo il codice che è stato creato in modo che gli sviluppatori non tirino il codice che romperebbe la loro build locale. Il PVC lo ha fatto abbastanza bene usando l'idea di gruppi di promozione. Clearcase potrebbe farlo anche con le etichette, ma richiederebbe una maggiore gestione dei processi rispetto a molti negozi che si occupano di fornire.

Answer 16

Un server build è utilizzato per programmare la compilazione compiti (ad esempio nightly build) di solito grandi progetti situati in un repository che a volte può richiedere più di un paio d'ore.

Answer 17

Un server di build fornisce anche una base per l'impegno, in grado di acquisire tutte le parti necessarie per riprodurre una build nel caso in cui altri possano avere diritti di proprietà.

Answer 18

Per aggiungere su quanto è già stato detto:

un ex collega lavorato nel team di Microsoft Office e mi ha detto una build completa a volte ha preso 9 ore. Questo farebbe schifo per farlo sulla macchina TUA, no?