Qual è il punto di un "Build Server"? [chiuso]

Non ho lavorato per organizzazioni molto grandi e non ho mai lavorato per un'azienda che avesse un "Build Server".

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

L'unico posto in cui vedo un Build Server utile è l'integrazione continua con il build server che costruisce costantemente ciò che è impegnato nel repository. È solo che non ho lavorato a progetti abbastanza grandi?

Qualcuno, per favore, mi illumini: qual è lo scopo di un server di compilazione?

Il motivo addotto è in realtà un enorme vantaggio. Le build che vanno al controllo di qualità dovrebbero provenire solo da un sistema che compila solo dal repository. In questo modo i pacchetti di compilazione sono riproducibili e tracciabili. Gli sviluppatori che creano manualmente codice per qualsiasi cosa tranne che per i propri test sono pericolosi. Troppo rischio che le cose non vengano archiviate, che non siano aggiornate con le modifiche di altre persone, ecc. Ecc.

Joel Spolsky su questo argomento.

I server di compilazione sono importanti per diversi motivi.

• Isolano l'ambiente Lo sviluppatore locale di Code Monkey dice "Si compila sulla mia macchina" quando non si compila sulla tua. Ciò può significare check-in non sincronizzati o potrebbe significare che manca una libreria dipendente. Jar hell non è così grave come .dll hell; in entrambi i casi, l'utilizzo di un server di compilazione è un'assicurazione economica che le tue build non falliranno misteriosamente o impacchetteranno le librerie sbagliate per errore.

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

• Coordinano lo sviluppo (distribuito). Il caso standard è dove più sviluppatori lavorano sulla stessa base di codice. Il sistema di controllo della versione è il cuore di questo tipo di sviluppo distribuito, ma a seconda dello strumento, gli sviluppatori potrebbero non interagire molto con il codice dell'altro. Invece di costringere gli sviluppatori a rischiare build sbagliate o preoccuparsi di unire il codice in modo eccessivamente aggressivo, progetta il processo di compilazione in cui la build automatizzata può vedere il codice appropriato ed elabora gli artefatti di build in modo prevedibile. In questo modo, quando uno sviluppatore commette qualcosa con un problema, come non archiviare una nuova dipendenza da file, può essere avvisato rapidamente. Facendo ciò in un'area a fasi è possibile contrassegnare il codice che è stato compilato in modo che gli sviluppatori non eseguano il pull del codice che interromperebbe la build locale. PVCS lo ha fatto abbastanza bene utilizzando l'idea dei gruppi di promozione. Anche Clearcase potrebbe farlo utilizzando le etichette, ma richiederebbe una gestione dei processi maggiore di quella fornita da molti negozi.

Qual è il loro scopo?
Prendi il carico di macchine per sviluppatori, fornisci un ambiente stabile e riproducibile per le build.

Perché gli sviluppatori non stanno costruendo il progetto sulle loro macchine locali, o lo sono?
Perché con un software complesso, sorprendentemente molte cose possono andare storte solo "compilando". problemi che ho effettivamente riscontrato:

• controlli delle dipendenze incompleti di diverso tipo, con conseguente mancato aggiornamento dei binari.
• Pubblica i comandi in modo non presidiato, il messaggio di errore nel registro viene ignorato.
• Compilare includendo sorgenti locali non ancora impegnate nel controllo del codice sorgente (fortunatamente, nessuna finestra di messaggio "maledetti clienti" ancora ..).
• Quando si tenta di evitare il problema di cui sopra creando da un'altra cartella, alcuni file vengono selezionati dalla cartella sbagliata.
• La cartella di destinazione in cui vengono aggregati i file binari contiene file per sviluppatori obsoleti aggiuntivi che non dovrebbero essere inclusi nella versione

Abbiamo ottenuto un incredibile aumento della stabilità poiché tutte le versioni pubbliche iniziano con un trasferimento dal controllo del codice sorgente a una cartella vuota. Prima c'erano molti "problemi divertenti" che "andavano via quando Joe mi dava 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 build batch sulla mia macchina locale, ci sono molte cose che non posso fare. Piuttosto che pagare gli sviluppatori per le build da completare, paga l'IT per acquistare già una macchina di build reale.

È solo che non ho lavorato a progetti abbastanza grandi?

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

Un server di compilazione è 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 di compilazione per creare il progetto (in genere una versione, contro una revisione con tag) in un ambiente pulito. Assicura che nessun hack dello sviluppatore, aggiustamenti, versioni di configurazione / artefatto non approvate o codice non confermato entri nel codice rilasciato.

Il server di compilazione viene utilizzato per creare il codice di tutti quando viene archiviato. Il codice può essere compilato localmente, ma molto probabilmente non avrai tutte le modifiche apportate da tutti gli altri tutto il tempo.

Per aggiungere quanto già detto:

Un ex collega ha lavorato nel team di Microsoft Office e mi ha detto che una build completa a volte richiedeva 9 ore. Farebbe schifo farlo sulla TUA macchina, no?

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

Sono d'accordo con le risposte finora per quanto riguarda stabilità, tracciabilità e riproducibilità. (Un sacco di 'ity's, giusto?). Avendo lavorato SOLO per grandi aziende (sanità, finanza) con MOLTI server di build, aggiungerei che si tratta anche di 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 testa ... BOOM. Superman III.

Queste macchine vengono utilizzate per diversi motivi, tutti cercando di aiutarti a fornire un prodotto superiore.

Un utilizzo è simulare una tipica configurazione dell'utente finale. Il prodotto potrebbe funzionare sul tuo computer, con tutti gli strumenti di sviluppo e le librerie configurati, ma molto probabilmente l'utente finale non avrà la tua stessa configurazione. Del resto, anche altri sviluppatori non avranno la stessa identica configurazione di te. Se hai un percorso hardcoded da qualche parte nel codice, probabilmente funzionerà sulla tua macchina, ma quando Dev El O'per cerca di 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. Ogni volta che il nuovo codice viene archiviato, il server di compilazione lo costruisce e, se fallisce, è chiaro che qualcosa non va e che l'utente che ha eseguito il commit per ultimo è colpevole.

Per una qualità costante e per ottenere la build "dalla macchina" per individuare gli errori dell'ambiente e in modo che tutti i file che si dimentica di archiviare nel controllo del codice sorgente vengano visualizzati anche come errori di compilazione.

Lo uso anche per creare programmi di installazione poiché richiedono molto tempo sul desktop con la firma del codice, ecc.

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

Per noi si tratta di gestione e test. Con un server di compilazione sappiamo sempre che possiamo costruire la nostra linea principale "trunk" dal controllo della versione. Possiamo creare un'installazione principale con un clic e pubblicarla sul web. Possiamo eseguire tutti i nostri test unitari ogni volta che il codice viene controllato per assicurarci che funzioni. Raccogliendo tutte queste attività in una singola macchina, è più facile farlo ripetutamente correttamente.

Hai ragione che gli sviluppatori potrebbero costruire sulle proprie macchine.

Ma queste sono alcune delle cose che il nostro server di build ci compra e non siamo produttori di build sofisticati:

• Problemi di controllo della versione (alcuni sono stati menzionati nelle risposte precedenti)
• Efficienza. Gli sviluppatori non devono fermarsi per creare build in locale. Possono avviarlo sul server e passare all'attività successiva. Se le build sono grandi, è ancora più tempo che la macchina dello sviluppatore non è occupata. Per coloro che fanno integrazione continua e test automatizzati, ancora meglio.
• Centralizzazione. La nostra macchina di compilazione ha script che realizzano la compilazione, la distribuiscono agli ambienti UAT e persino alla fase di produzione. Tenerli in un unico posto riduce il fastidio di mantenerli sincronizzati.
• Sicurezza. Non facciamo molto di 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 compilazione da determinate entità autorizzate.

Forse sono l'unico ...

Penso che tutti siano d'accordo che si dovrebbe

• utilizzare un repository di file
• fare build dal repository (e in un ambiente pulito)
• usa un server di test continuo (es. cruise control) per vedere se qualcosa è rotto dopo le tue "correzioni"

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

Quando vuoi creare una versione di rilascio, esegui una build dal repository. E sono abbastanza sicuro che tu voglia taggare la versione nel repository in quel momento e non ogni sei ore quando il server funziona.

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

Un server di compilazione ti dà una sorta di seconda opinione del tuo codice. Quando lo fai il check-in, il codice viene controllato. Se funziona, il codice ha una qualità minima.

Inoltre, ricorda che la compilazione dei linguaggi di basso livello richiede molto più tempo rispetto ai linguaggi di alto livello. È facile pensare "Beh, guarda, il mio progetto .Net si compila in un paio di secondi! Qual è il problema?" Tempo fa ho dovuto pasticciare con un po 'di codice C e avevo dimenticato quanto tempo ci vuole per compilare.

Un server di compilazione viene utilizzato per pianificare le attività di compilazione (ad es. Build notturne) di progetti solitamente di grandi dimensioni situati in un repository che a volte possono richiedere più di un paio d'ore.

Un server di build ti offre anche una base per l'escrow, essendo in grado di catturare tutte le parti necessarie per riprodurre una build nel caso in cui altri possano avere i diritti per prenderne la proprietà.