Quali sono i vantaggi degli script di build?

Automation.

Durante lo sviluppo, solo nei progetti più semplici il pulsante "build" predefinito farà tutto ciò che ti serve; potrebbe essere necessario creare WS fuori dalle API, generare documenti, collegarsi con risorse esterne, distribuire le modifiche su un server, ecc. Alcuni IDE consentono di personalizzare il processo di generazione aggiungendo ulteriori passaggi o builder, ma ciò significa solo che si è generare il tuo script di build attraverso le commodity IDE.

Ma lo sviluppo di un sistema non è solo la scrittura di codice. Ci sono più passaggi coinvolti. Uno script indipendente IDE può essere eseguito automaticamente, ovvero:

• Quando si commette una modifica al controllo della versione, una nuova build può essere avviata automaticamente dal server. Assicurerà di non aver dimenticato di impegnare nulla di necessario per la compilazione.

• Analogamente, una volta completata la compilazione, i test possono essere eseguiti automaticamente per vedere se hai rotto qualcosa.

• Ora il resto dell'organizzazione (QA, amministratori di sistema) ha un prodotto costruito che

  a) è perfettamente riproducibile solo dalla versione di controllo.

  b) è comune a tutti loro.

Anche quando ho lavorato come team one man ho usato script per questo scopo; quando ho sviluppato la correzione, mi impegnerei a SVN, esportare il SVN in un'altra directory e utilizzare lo script build per generare la soluzione, che andrebbe poi ai sistemi di pre-produzione e in seguito alla produzione. Se qualche settimana più tardi (con la mia base di codice locale già cambiata) qualcuno si lamentava di un bug, sapevo esattamente quale revisione SVN avrei dovuto eseguire per eseguire il debug del sistema.

Come il codice, uno script di build viene eseguito dal computer. I computer sono eccezionalmente bravi a seguire una serie di istruzioni. Infatti, (al di fuori del codice auto-modificante), i computer eseguiranno la stessa sequenza di istruzioni esattamente allo stesso modo, dato lo stesso input. Questo offre un livello di coerenza che, beh, solo un computer può eguagliare.

Al contrario, noi sacchi di carne pieni d'acqua sono semplicemente spregevoli quando si tratta di seguire i passi. Quel fastidioso cervello analitico ha la tendenza a mettere in discussione tutto ciò che incontra. "Oh ... non ho bisogno di farlo", o "Devo davvero usare questa bandiera? Eh ... Lo ignorerò." Inoltre, abbiamo la tendenza ad essere compiacenti. Una volta che abbiamo fatto qualcosa alcune volte, iniziamo a credere che conosciamo le istruzioni e non dobbiamo guardare il foglio di istruzioni.

Da "The Pragmatic Programmer":

In addition, we want to ensure consistency and repeatability on the project. Manual procedures leave consistency up to change; repeatability isn't guaranteed, especially if aspects of the procedure are open to interpretation by different people.

Inoltre, HILARIOUSLY è lento nelle istruzioni di esecuzione (rispetto a un computer). In un progetto di grandi dimensioni, con centinaia di file e configurazioni, sarebbero necessari anni per eseguire manualmente tutti i passaggi in un processo di compilazione.

Ti darò un esempio del mondo reale. Stavo lavorando su software embedded, in cui la maggior parte del codice era condivisa su alcune piattaforme hardware diverse. Ogni piattaforma aveva hardware diverso, ma la maggior parte del software era la stessa. Ma c'erano piccoli pezzi specifici per ogni hardware. Idealmente, i pezzi comuni sarebbero collocati in una libreria e collegati in ogni versione. Tuttavia, i pezzi comuni non possono essere compilati in una libreria condivisa. Doveva essere compilato con ogni diversa configurazione.

In un primo momento, ho compilato manualmente ciascuna configurazione. Ci sono voluti solo pochi secondi per passare da una configurazione all'altra e non era un gran problema. Verso la fine del progetto, è stato scoperto un difetto critico nella parte condivisa del codice, in cui un dispositivo essenzialmente avrebbe occupato il bus di comunicazione. Questo è stato BAD! Veramente male. Ho trovato il bug nel codice, l'ho risolto e ricompilato ogni versione. Tranne uno. Durante il processo di costruzione, mi sono distratto e ne ho dimenticato uno. I binari sono stati rilasciati, la macchina è stata costruita e il giorno dopo ricevo una telefonata che dice che la macchina ha smesso di rispondere. Lo controllo e ho scoperto che un dispositivo aveva bloccato il bus. "Ma ho corretto quell'insetto!".

Potrei averlo risolto, ma non è mai stato trovato su quella scheda. Perché? Perché non avevo un processo di compilazione automatizzato che costruisse ogni singola versione con 1 clic.

Se tutto ciò che si vuole fare è <compiler> **/*.<extension> , gli script di compilazione servono poco (anche se si può sostenere che se si vede un Makefile nel progetto si sa che è possibile costruirlo con make ). Il fatto è che i progetti non banali di solito richiedono più di questo - per lo meno, di solito è necessario aggiungere librerie e (con la maturazione del progetto) configurare i parametri di costruzione.

Gli IDE di solito sono almeno configurabili, ma ora il processo di costruzione si basa su opzioni specifiche per IDE. Se stai utilizzando Eclipse , Alice preferisce NetBeans , e Bob vuole utilizzare IntelliJ IDEA , non è possibile condividere il configurazione, e quando uno di voi spinge una modifica al controllo del codice sorgente, è necessario modificare manualmente i file di configurazione creati dagli IDE degli altri sviluppatori o avvisare gli altri sviluppatori in modo che lo facciano da soli (il che significa che ci sarà commette dove la configurazione IDE è errata per alcuni IDE ...).

Devi anche capire come fare quel cambiamento in ognuno degli IDE usati dal team, e se uno di loro non supporta quella particolare impostazione ...

Ora, questo problema dipende dalla cultura: i tuoi sviluppatori potrebbero ritenere accettabile la mancanza di IDE. Ma gli sviluppatori che hanno esperienza con un IDE sono solitamente più felici e più efficienti quando lo usano, e gli utenti di text-editor tendono a diventare religiosamente zeloti dei loro strumenti preferiti, quindi questo è uno dei luoghi in cui si vuole dare libertà agli sviluppatori - e costruire sistemi ti permettono di fare proprio questo. Alcune persone potrebbero avere una preferenza per il sistema di compilazione, ma non è altrettanto fanatica delle preferenze IDE / editor ...

Anche se si ottiene che tutti gli sviluppatori utilizzino lo stesso IDE - buona fortuna a convincere il server di build a usarlo ...

Ora, questo è per le semplici personalizzazioni del processo di compilazione, che gli IDE tendono a fornire una buona GUI. Se vuoi cose più complesse - come pre-processare / auto-generare i file sorgente prima della compilazione - di solito devi scrivere uno script pre-compilato in qualche area di testo di base all'interno della configurazione dell'IDE. Quali sistemi di compilazione dovresti ancora codificare quella parte, ma puoi farlo nell'editor attuale in cui scrivi il codice, e ancora più importante: la stessa struttura del sistema di compilazione di solito fornisce un supporto per l'organizzazione di questi script.

Infine - i sistemi di compilazione sono utili per qualcosa di più della semplice costruzione del progetto - è possibile programmarli per svolgere altre attività che potrebbero essere eseguite da chiunque nel team. In Ruby on Rails , ad esempio, sono presenti attività di sistema per l'esecuzione di migrazioni di database, per la pulizia di file temporanei, ecc. Mettere queste attività nel sistema di costruzione garantisce che tutti nel team possano eseguirle in modo coerente.

Molti IDE semplicemente impacchettano i comandi usati per costruire qualcosa e poi generano uno script e lo chiamano!

Ad esempio, in Visual Studio, è possibile visualizzare i parametri della riga di comando per una compilazione C ++ nella casella 'riga di comando'. Se guardi da vicino l'output di build vedrai il file temporaneo che contiene lo script di build che è stato usato per eseguire la compilazione.

Al giorno d'oggi, è tutto MSBuild , ma viene comunque eseguito direttamente dall'IDE.

Quindi il motivo per cui usi la riga di comando è che stai andando direttamente alla fonte e saltando il middle man, un intermediario che potrebbe essere stato aggiornato o richiedere un mucchio di dipendenze che non vuoi o di cui hai bisogno in un server senza testa che funge da server integrazione continua (CI)

Inoltre, i tuoi script fanno più dei soliti passi orientati agli sviluppatori per i quali sono progettati. Ad esempio, dopo una compilazione, è possibile che i file binari siano raggruppati e copiati in un percorso speciale oppure che venga creato un pacchetto di installazione o che venga eseguito uno strumento di documentazione. Molte attività diverse vengono eseguite da un server CI che non ha senso su una macchina per sviluppatori, quindi mentre si può creare un progetto IDE che eseguiva tutti questi passaggi dovresti quindi mantenerne due: un progetto per gli sviluppatori e un altro per le build. Alcune attività di compilazione (ad esempio l'analisi statica) possono richiedere molto tempo che non vorresti per i progetti dello sviluppatore.

In breve, però, è più semplice: crea uno script per fare tutto ciò che desideri ed è semplice e veloce dare il via alla riga di comando o alla configurazione del build server.

make

è molto più facile da ricordare e scrivere di

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h

E i progetti possono avere comandi di compilazione molto complessi. Uno script di build ha anche la capacità di ricompilare solo le cose che sono cambiate. Se vuoi fare una compilazione pulita,

make clean

è più semplice e affidabile una volta configurato correttamente rispetto al tentativo di ricordare ogni luogo in cui un file intermedio potrebbe essere stato prodotto.

Naturalmente, se si utilizza un IDE, anche facendo clic su un pulsante di compilazione o di pulizia. Tuttavia, è molto più difficile automatizzare lo spostamento del cursore in un punto specifico sullo schermo, specialmente quando quel luogo può spostarsi se si muove la finestra, piuttosto che automatizzare un semplice comando di testo.

In quale altro modo lo faresti? L'unico altro modo è specificare un lungo comando da riga di comando.

Un altro motivo è che i makefile consentono la compilazione incrementale, che accelera molto il tempo di compilazione.

I makefile possono anche creare un processo di compilazione multipiattaforma. CMake genera diversi script di compilazione basati sulla piattaforma.

Modifica:

Con un IDE, sei legato a un modo particolare di fare le cose. Molte persone usano vim o emacs anche se non hanno molte caratteristiche simili all'IDE. Lo fanno perché vogliono il potere che forniscono questi editor. Gli script di compilazione sono necessari per coloro che non utilizzano un IDE.

Anche per chi usa un IDE, potresti voler sapere veramente cosa sta succedendo, quindi lo script di build ti offre i dettagli di basso livello dell'implementazione che un approccio GUI non ha.

Gli stessi IDE utilizzano spesso anche internamente gli script; il pulsante Esegui è solo un altro modo di eseguire il comando make.

Le risposte di cui sopra coprono un sacco di buone basi, ma un esempio del mondo reale che vorrei aggiungere (che non posso aggiungere come commento a causa di nessun karma), è dalla programmazione Android.

Sono uno sviluppatore professionista per Android / iOS / Windows Phone e utilizzo le API dei servizi di Google (principalmente Google Maps) un lotto .

In Android, questi servizi richiedono l'aggiunta di un keystore , o un tipo di file ID sviluppatore che indica a Google che io sono chi dico di essere, a una console per sviluppatori. Se la mia app è compilata con un keystore diverso, la sezione dell'app Google Maps non funzionerà.

Invece di aggiungere e gestire una dozzina di keystore alla console degli sviluppatori, solo uno dei due può essere effettivamente utilizzato per aggiornare l'app, includo questo keystore nel nostro repository sicuro e uso Gradle per dire esattamente a Android Studio quale keystore usare quando si costruisce per "debug" o "release". Ora, devo solo aggiungere due keystore alla mia console per sviluppatori di Google, uno per "debug" e uno per "release", e tutti i membri del mio team possono clonare il repository e ottenere lo sviluppo corretto senza dover accedere all'app console e aggiungi l'hash SHA del loro particolare keystore o, peggio, facendoli gestire . Questo ha l'ulteriore vantaggio di fornire ad ogni membro del team una copia del keystore della firma, il che significa che se sono fuori sede e un aggiornamento è pianificato, un membro del team deve solo seguire un breve elenco di istruzioni per spingere un aggiornamento.

Costruire un'automazione come questa mantiene costanti le build e riduce il debito tecnico riducendo drasticamente i tempi di set-up quando otteniamo un nuovo sviluppatore, una nuova macchina o quando dobbiamo ri-immaginare una macchina.

Vantaggi dello script di costruzione:

• le modifiche appaiono come codice (ad esempio, in un comando git diff), non come le diverse opzioni controllate in una finestra di dialogo

• creare più output di una semplice build

In alcuni dei miei progetti precedenti, ho usato gli script di compilazione per:

• genera la documentazione del progetto (basata su doxygen)
• costruire
• esegui test di unità
• genera rapporti di copertura del test unitario
• comprimi i binari in un archivio di rilascio
• genera note di rilascio interne (basate sui messaggi "git log")
• test automatici

Spesso è possibile chiamare il pulsante "build" in modo automatico (Visual Studio accetta argomenti della riga di comando, ad esempio). Le persone scrivono gli script di build non appena hanno bisogno di qualcosa che il pulsante di costruzione non può fornire.

Ad esempio, la maggior parte degli IDE ti consente solo di creare una piattaforma alla volta. O solo una lingua alla volta. Poi c'è quello che fai con gli output costruiti: il tuo IDE può caricarli tutti in un pacchetto di installazione?