Responsabilità di Build Script e Build Server

Ho bisogno di alcuni chiarimenti sulle responsabilità di Build Script e Build Server.

Ho letto diversi articoli su Internet sull'integrazione e le build continue. Compreso

E ho avuto una conversazione con il mio consulente sul processo di creazione del nostro software. Perché ha molta esperienza, mi fido delle sue dichiarazioni, ma sono rimasto confuso.

A quanto ho capito, dalla mia ricerca (e per favore correggimi qui, poiché è quello che sto chiedendo) l'ideale dovrebbe essere il seguente:

ogni progetto ha il suo script di compilazione
questo script costruisce il progetto
questo script assicura che le dipendenze siano state costruite in precedenza

Poiché le dipendenze potrebbero essere un altro progetto, con il proprio script di build si accumula una gerarchia ad albero. Potrebbe esserci uno script di build principale che crea tutti i progetti e le applicazioni.

Tuttavia le responsabilità del Build Server sono:

controlla il repository
innescare la build
innescare test e altri strumenti di controllo qualità
rendere disponibile l'artefatto

Questo può essere attivato manualmente, di notte o ogni volta che il repository cambia

Gli obiettivi del mio advisor sono, a quanto ho capito, che uno script di build è un modo per inflessibile e non mantenibile (A parte il fatto che ci vorrebbe molto tempo per crearne uno per la nostra base di codice legacy). Inoltre, Build Server dovrebbe mantenere le dipendenze, ad esempio per utilizzare dipendenze meno recenti quando si creano nuove dipendenze. E particolare per Antcome era l'argomento concreto, non è in grado di costruire tutti i tipi di tecnologie diverse che vengono utilizzate nella base di codice e non è in grado di mantenere le dipendenze.

Potete per favore elaborare gli obiettivi e chiarire le responsabilità?

version-control continuous-integration builds

— Angelo.Hannes
fonte

Anche se questa è una buona domanda, a cui verrà data risposta (lo farò più tardi quando avrò tempo e non ha ancora ricevuto risposta): dovresti davvero tornare indietro e ottenere chiarimenti dal tuo consulente. Essere confusi dopo una conversazione con qualcuno che valuterà le tue prestazioni è una ricetta per il disastro e un'indicazione che non stanno comunicando adeguatamente con te (o non stai ascoltando attivamente, ma non sembra essere il caso Qui).

— Steven Evers,

@ Angelo.Hannes Penso che tu abbia raggiunto tutti i punti principali. Puoi chiarire più specificamente ciò di cui sei confuso?

— M. Dudley,

@SteveEvers Bene, come ho appena letto alcune introduzioni a questo argomento, volevo prima espandere le mie conoscenze al riguardo. Sicuramente riprenderò di nuovo questo argomento. Pertanto apprezzerei davvero una tua risposta.

— Angelo.Hannes,

@ M.Dudley Come ho detto, non sono sicuro di quali responsabilità vadano. E se uno script di build per l'intero software è la strada giusta da percorrere.

— Angelo.Hannes,

Queste cose sono ortogonali:

Lo script di compilazione è il meccanismo che, su invocazione sull'albero dei sorgenti appena estratto, produce una build completa di obiettivi e dipendenze richiesti. Potrebbe essere semplicemente "fai tutto" se hai un makefile o un'opportuna invocazione di MSBuild, Ant, Maven o Scons. Se hai una complessa gerarchia di dipendenze o progetti correlati, il tuo 'script di compilazione' potrebbe essere un file di livello superiore che invoca ciascuno di essi a turno, verificando il successo mentre procedi.

Lo script di compilazione è solo uno degli script forse molti (checkout, build, test, package) ma potresti avere un meccanismo all-in-one controllato da parametri della riga di comando - dipende dal tuo ambiente.

Il server di compilazione , o piuttosto il server di integrazione continua , è il meccanismo di automazione responsabile della pianificazione / attivazione, monitoraggio e reportistica del checkout -> build -> test -> pacchetto -> stage -> deploy pipeline. Potresti usare cron / Task Scheduler se non avessi nulla di più sofisticato da gestire, ma ora ci sono molti strumenti eccellenti come Jenkins, Cruise Control, TeamCity, ecc.

È importante che puoi invocare una build senza utilizzare il server CI, nel caso in cui sia occupata / offline / non raggiungibile / altrimenti non disponibile, quindi la logica per ottenere la build / test / qualunque cosa sia fatta deve essere al di fuori del Sistema CI, ma è invocabile da esso, parametrizzato per ramo / tipo di build / versione / architettura, ecc.

— JBRWilkinson
fonte