Quali sono i vantaggi degli script di build?

Per gran parte della mia carriera di programmatore, ho usato il comando "build / compile / run" in qualunque IDE con cui sto lavorando per produrre un programma eseguibile. Questo è un pulsante, abbastanza facile. Mentre imparo di più su diverse lingue e framework, però, vedo sempre più discorsi di "script di build" (ANT, Maven, Gradle, ecc.) Per far funzionare un progetto. La mia comprensione di questi è che sono istruzioni per il compilatore / linker / magic-program-maker che specificano i dettagli di configurazione - minutiae.

Ricordo di aver scritto i makefile a scuola, ma allora non ho visto alcun vantaggio speciale (li abbiamo usati solo quando scrivevamo in un terminale Unix, dove un IDE con il suo comodo pulsante "build" non era presente). Oltre a ciò, ho visto altre domande qui che discutono di come gli script di build possano fare di più oltre a creare il tuo programma: possono eseguire unit test e risorse sicure indipendentemente dal computer host .

Non riesco a scuotere la sensazione che costruire script sia importante da capire come sviluppatore, ma vorrei una spiegazione significativa; perché dovrei usare / scrivere script di compilazione?

Le responsabilità di Build Script e Build Server discutono il ruolo che svolge in un ambito più ampio. Sto cercando vantaggi specifici offerti da uno script di build rispetto al comando "build / run" di IDE o metodi altrettanto semplici.

Automazione.

Durante lo sviluppo, solo nei progetti più semplici il pulsante "build" predefinito farà tutto ciò di cui hai bisogno; potrebbe essere necessario creare WS dalle API, generare documenti, collegarsi con risorse esterne, distribuire le modifiche su un server, ecc. Alcuni IDE consentono di personalizzare il processo di compilazione aggiungendo passaggi aggiuntivi o compilatori, ma ciò significa solo che si è generare lo script di compilazione tramite i prodotti IDE.

Ma sviluppare un sistema non è solo scrivere codice. Ci sono più passaggi coinvolti. Uno script IDE indipendente può essere eseguito automaticamente, nel senso che:

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

• Allo stesso modo, al termine della 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 integrato che

  a) è perfettamente riproducibile solo dalla versione di controllo.

  b) è comune a tutti loro.

Anche quando ho lavorato come un solo uomo ho usato gli script per quello scopo; una volta sviluppata la correzione, mi sarei impegnata a SVN, esportare nuovamente SVN in un'altra directory e utilizzare lo script build per generare la soluzione, che sarebbe poi passata ai sistemi di preproduzione e successivamente alla produzione. Se qualche settimana dopo (con la mia base di codice locale già modificata) qualcuno si fosse lamentato di un bug, avrei saputo esattamente quale revisione SVN avrei dovuto verificare per eseguire correttamente 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. In effetti, (al di fuori del codice di auto-modifica), i computer eseguiranno la stessa sequenza di istruzioni esattamente nello stesso modo, dato lo stesso input. Questo offre un livello di coerenza che, bene, solo un computer può eguagliare.

Al contrario, noi sacchetti di carne pieni d'acqua sono semplicemente spregevoli quando si tratta di seguire i passaggi. Quel fastidioso cervello analitico ha la tendenza a mettere in discussione tutto ciò che incontra. "Oh ... non ne ho bisogno", o "Devo davvero usare questa bandiera? Eh ... La ignorerò e basta." Inoltre, abbiamo la tendenza a diventare compiacenti. Una volta che abbiamo fatto qualcosa alcune volte, iniziamo a credere di conoscere le istruzioni e di non dover guardare il foglio delle istruzioni.

Da "The Pragmatic Programmer":

Inoltre, vogliamo garantire coerenza e ripetibilità sul progetto. Le procedure manuali lasciano la coerenza al cambiamento; la ripetibilità non è garantita, soprattutto se gli aspetti della procedura sono aperti all'interpretazione di persone diverse.

Inoltre, siamo ESENTAMENTE LENTAMENTE nell'esecuzione delle istruzioni (rispetto a un computer). Su un grande progetto, con centinaia di file e configurazioni, occorrerebbero anni per eseguire manualmente tutte le fasi di un processo di compilazione.

Ti darò un esempio del mondo reale. Stavo lavorando con un software incorporato, 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 ciascuna versione. Tuttavia, i pezzi comuni non possono essere compilati in una libreria condivisa. Doveva essere compilato con ogni diversa configurazione.

Inizialmente, ho compilato manualmente ogni configurazione. Ci sono voluti solo pochi secondi per passare da una configurazione all'altra, e non è stato un gran problema. Verso la fine del progetto, è stato scoperto un difetto critico nella parte condivisa del codice, in cui un dispositivo avrebbe sostanzialmente assunto il bus di comunicazione. Questo era MALE! Veramente male. Ho trovato il bug nel codice, risolto e ricompilato ogni versione. Tranne uno. Durante il processo di creazione, mi sono distratto e me ne sono dimenticato. 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. Ho controllato e ho scoperto che un dispositivo aveva bloccato il bus. "Ma ho corretto quel bug!".

Potrei averlo corretto, ma non ha mai trovato la sua strada su quella scheda. Perché? Perché non avevo un processo di compilazione automatizzato che creava ogni singola versione con 1 clic.

Se tutto ciò che vuoi fare è <compiler> **/*.<extension>, gli script di compilazione hanno uno scopo limitato (sebbene si possa sostenere che se vedi un Makefileprogetto nel quale sai che puoi costruirlo make). Il fatto è che i progetti non banali di solito richiedono più di questo, per lo meno, di solito è necessario aggiungere librerie e (man mano che il progetto matura) configurare i parametri di compilazione.

Gli IDE sono in genere almeno configurabili, ma ora il processo di compilazione si basa su opzioni specifiche dell'IDE. Se si utilizza Eclipse , Alice preferisce NetBeans e Bob desidera utilizzare IntelliJ IDEA , non è possibile condividere la configurazione e quando uno di voi invia una modifica al controllo del codice sorgente, deve modificare manualmente la configurazione creata dall'IDE file degli altri sviluppatori o avvisa gli altri sviluppatori in modo che lo facciano da soli (il che significa che ci saranno commit in cui la configurazione IDE è sbagliata per alcuni degli 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 trovare accettabile non avere la scelta di IDE. Ma gli sviluppatori che hanno esperienza con un IDE sono generalmente più felici ed efficienti quando lo usano, e gli utenti dell'editor di testi tendono a diventare religiosamente zelanti sui loro strumenti preferiti, quindi questo è uno dei luoghi in cui vuoi dare libertà agli sviluppatori - e costruire sistemi ti permettono di fare proprio questo. Alcune persone potrebbero avere una preferenza di sistema build, ma non è così fanatica come le preferenze IDE / editor ...

Anche se fai in modo 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, per le quali gli IDE tendono a fornire una buona interfaccia grafica. Se vuoi cose più complesse - come pre-elaborazione / generazione automatica di file sorgente prima della compilazione - di solito dovrai scrivere uno script pre-build in un'area di testo di base all'interno della configurazione dell'IDE. In quali sistemi di build dovresti ancora codificare quella parte, ma puoi farlo nell'editor reale in cui scrivi il codice e, cosa più importante: lo stesso framework del sistema di build in genere fornisce un supporto per l'organizzazione di questi script.

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

Molti IDE semplicemente impacchettano i comandi usati per costruire qualcosa e quindi generare uno script e chiamarlo!

Ad esempio, in Visual Studio, è possibile visualizzare i parametri della riga di comando per una compilazione C ++ nella casella "Riga di comando". Se osservi attentamente l'output di build vedrai il file temporaneo che contiene lo script di build utilizzato per eseguire la compilazione.

Al giorno d'oggi, è tutto MSBuild , ma è ancora gestito direttamente dall'IDE.

Quindi la ragione per cui usi la riga di comando è che stai andando direttamente alla fonte e salti l'uomo intermedio, un intermediario che potrebbe essere stato aggiornato o richiedere un mucchio di dipendenze che semplicemente non vuoi o di cui hai bisogno su un server senza testa che funge da server di integrazione continua (CI).

Inoltre, i tuoi script fanno più dei soliti passaggi orientati agli sviluppatori per cui sono progettati. Ad esempio, dopo una compilazione, è possibile che i file binari vengano impacchettati e copiati in una posizione 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 sono inutili su una macchina sviluppatore, quindi mentre è possibile creare un progetto IDE che esegua tutti questi passaggi, è necessario mantenerne due: un progetto per sviluppatori e un altro per build. Alcune attività di compilazione (ad esempio analisi statica) possono richiedere molto tempo che non si vorrebbe per progetti di sviluppo.

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

make

è molto più facile da ricordare e digitare 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 possibilità di ricompilare solo le cose che sono cambiate. Se vuoi fare una build pulita,

make clean

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

Naturalmente, se usi un IDE, fai clic anche su un pulsante di creazione o pulizia semplice. Tuttavia, è molto più difficile automatizzare lo spostamento del cursore in un punto specifico dello schermo, soprattutto quando quel luogo può spostarsi se la finestra si sposta, 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 i tempi di compilazione.

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

Modificare:

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

Anche per coloro che usano un IDE, potresti voler davvero sapere cosa sta succedendo, quindi lo script di build ti offre i dettagli più bassi dell'implementazione che un approccio GUI non ha.

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

Le risposte di cui sopra coprono molto terreno, ma un esempio del mondo reale che vorrei aggiungere (che non posso aggiungere come commento a causa del karma), è della programmazione Android.

Sono un professionista sviluppatore Android / iOS / Windows Phone, e io uso Google API dei servizi (soprattutto Google Maps) un sacco .

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

Invece di aggiungere e gestire una dozzina di keystore alla console degli sviluppatori, solo uno dei quali può effettivamente essere utilizzato per aggiornare l'app comunque, includo questo keystore nel nostro repository sicuro e uso Gradle per dire ad Android Studio esattamente quale keystore usare quando si costruisce per "debug" o "release". Ora, devo solo aggiungere due keystore alla mia console per gli sviluppatori di Google, uno per "debug" e uno per "release", e tutti i membri del mio team possono clonare il repository e iniziare a sviluppare senza dover passare allo sviluppatore console e aggiungere l'hash SHA del loro particolare keystore, o peggio, facendomi gestire. Ciò ha l'ulteriore vantaggio di fornire a ciascun membro del team una copia del keystore di firma, il che significa che se sono fuori sede e è previsto un aggiornamento, un membro del team deve solo seguire un breve elenco di istruzioni per inviare un aggiornare.

L'automazione della build in questo modo mantiene costanti le build e riduce il debito tecnico riducendo i tempi di configurazione quando otteniamo un nuovo sviluppatore, una nuova macchina o quando dobbiamo ricreare l'immagine di una macchina.

Costruisci i vantaggi dello script:

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

• creando più output di una semplice build

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

• generare la documentazione del progetto (basata su doxygen)
• costruire
• eseguire test unitari
• generare rapporti sulla copertura dei test unitari
• comprimere i file binari in un archivio di rilascio
• generare note di rilascio interne (basate su messaggi "git log")
• test automatizzati

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

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