Quali sono i vantaggi degli script di compilazione?

Automazione.

Quando sviluppi, solo nei progetti più semplici il pulsante predefinito “build” farà tutto ciò che ti serve; potresti dover creare WS dalle API, generare documenti, collegarti a risorse esterne, distribuire le modifiche a un server, ecc. Alcuni IDE ti consentono di personalizzare il processo di compilazione aggiungendo passaggi o builder aggiuntivi, ma questo significa solo che sei generare il tuo script di compilazione tramite i prodotti IDE.

Ma sviluppare un sistema non significa solo scrivere codice. Ci sono più passaggi coinvolti. Uno script indipendente dallIDE può essere eseguito automaticamente, il che significa che:

• Quando effettui una modifica al controllo della versione, una nuova build può essere lanciata automaticamente dal server. Garantirà che non ti sia dimenticato di eseguire il commit di nulla di necessario per la compilazione.

• Allo stesso modo, dopo che la compilazione è terminata, i test possono essere eseguiti automaticamente per vedere se hai rotto qualcosa.

• Ora il resto dellorganizzazione (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 un team di un solo uomo ho usato script per quello scopo; dopo aver sviluppato la correzione, mi sarei impegnato in SVN, esportato nuovamente SVN in unaltra directory e utilizzato lo script di compilazione per generare la soluzione, che sarebbe andata poi ai sistemi di preproduzione e successivamente alla produzione. Se poche settimane 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 controllare per eseguire correttamente il debug del sistema.

Commenti

• Questa è la migliore risposta IMHO. Tutti hanno ragione con la loro idea, ma questa mostra davvero perché vuoi creare script. Perché supportano lautomazione che va avanti man mano che il tuo progetto si espande ti farà risparmiare un sacco di tempo.
• @Alexus Non solo tempo, ma anche stupidi errori. 😉 ” La ripetizione porta alla noia. La noia porta a errori orribili. Errori orribili portano a ‘ Vorrei essere ancora annoiato.’ ” (potresti anche misurare errori stupidi nel tempo, ma ‘ importante rendersi conto che ‘ ti fa risparmiare tempo per diverse cause.)
• Anche per i progetti individuali, eseguire un server Jenkins locale per automatizzare il ” compilato in una directory separata ” può aiutare. ‘ sto lavorando su qualcosa in Windows che devo confermare anche con cross-compilazioni, quindi avere Jenkins che compila ed esegue test, quindi compila la versione cross-compilata mi rende molto più sicuro ( ed efficiente, ovviamente!) quando ho bisogno di rilasciare correzioni di bug.
• Non ‘ sono daccordo con largomento delle build riproducibili. Ci sono così tante variabili incontrollate nei sistemi di compilazione odierni che è piuttosto difficile ottenere build riproducibili. Il tuo argomento suona come se riuscissi a ottenere quello fuori dagli schemi, il che non è assolutamente vero.
• @JonasGr ö ger Lautomazione elimina uno dei variabili più grandi: gli esseri umani.

Come il codice, uno script di compilazione viene eseguito dal computer. I computer sono eccezionalmente bravi nel seguire una serie di istruzioni. Infatti, (al di fuori del codice auto-modificante), i computer eseguiranno la stessa sequenza di istruzioni esattamente nello 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 dacqua siamo 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”, oppure “Devo davvero usare questa bandiera? Eh … Lo ignorerò. ” Inoltre, abbiamo la tendenza a diventare compiacenti. Una volta che abbiamo fatto qualcosa un paio di volte, iniziamo a credere di conoscere le istruzioni e non dobbiamo guardare il foglio di istruzioni.

Da “The Pragmatic Programmer”:

Inoltre, vogliamo garantire la coerenza e la ripetibilità del progetto. Le procedure manuali lasciano la coerenza al cambiamento; la ripetibilità non è garantita, soprattutto se alcuni aspetti della procedura sono aperti allinterpretazione da parte di persone diverse.

Inoltre, siamo ILLARITAMENTE lenti nellesecuzione delle istruzioni ( rispetto a un computer). In un progetto di grandi dimensioni, con centinaia di file e configurazioni, ci vorrebbero anni per eseguire manualmente tutti i passaggi di un processo di compilazione.

Ti darò un esempio del mondo reale. Stavo lavorando su alcuni software incorporati, in cui la maggior parte del codice era condivisa su diverse piattaforme hardware. Ogni piattaforma aveva hardware diverso, ma la maggior parte del software era la stessa. Ma cerano piccoli pezzi specifici per ogni hardware. Idealmente, i pezzi comuni dovrebbero essere inseriti in una libreria e collegati a ciascuna versione. Tuttavia, i pezzi comuni non potevano essere compilati in una libreria condivisa. Doveva essere compilato con ogni diversa configurazione.

Allinizio, ho compilato manualmente ogni configurazione. Ci sono voluti solo pochi secondi per passare da configurazioni, e non era così grande di un dolore. Verso la fine del progetto, è stato scoperto un difetto critico nella porzione di codice condivisa, dove un dispositivo avrebbe essenzialmente preso il controllo del bus di comunicazione. Questo era MALE! Veramente male. Ho trovato il bug nel codice, lho corretto e ho 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 diceva che la macchina aveva smesso di rispondere. Ho controllato e ho scoperto che un dispositivo aveva bloccato lautobus. “Ma ho risolto quel bug!”.

Potrei averlo risolto, ma non è mai riuscito a trovare la sua strada su quella scheda. Perché? Perché non avevo un processo di compilazione automatizzato che costruisse ogni singola versione con 1 clic.

Commenti

• E puoi andare a prendere un caffè mentre il lo script di build è in esecuzione!

Se tutto ciò che vuoi è <compiler> **/*.<extension>, gli script di compilazione servono a poco (anche se si può sostenere che se vedi un Makefile nel progetto sai che puoi costruirlo con make). Il fatto è che i progetti non banali di solito richiedono più di questo – per lo meno, di solito dovrai aggiungere librerie e (man mano che il progetto matura) configurare i parametri di compilazione.

Gli IDE di solito sono almeno così configurabili, ma ora il processo di compilazione si basa su opzioni specifiche dellIDE.Se stai utilizzando Eclipse , Alice preferisce NetBeans e Bob desidera utilizzare IntelliJ IDEA , non puoi “t condividere la configurazione e quando uno di voi invia una modifica al controllo del codice sorgente, deve modificare manualmente i file di configurazione creati dallIDE gli altri sviluppatori, o avvisare 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 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 degli IDE. Ma gli sviluppatori che hanno esperienza con un IDE di solito sono sia più felici che più efficienti quando lo usano, e gli utenti di editor di testo tendono a diventare religiosamente fanatici del loro preferito ols, quindi questo è uno dei posti in cui vuoi dare libertà agli sviluppatori e costruire sistemi ti permette di fare proprio questo. Alcune persone potrebbero avere una preferenza di sistema di compilazione, ma non è così fanatica come le preferenze di IDE / editor …

Anche se fai in modo che tutti gli sviluppatori usino lo stesso IDE, buona fortuna a convincere la build server per usarlo …

Ora, questo è per le semplici personalizzazioni del processo di compilazione, per cui gli IDE tendono a fornire una bella GUI. Se vuoi cose più complesse – come la pre-elaborazione / generazione automatica di file sorgente prima della compilazione – di solito dovrai scrivere uno script di pre-compilazione in qualche area di testo di base allinterno della configurazione dellIDE. Quali sistemi di compilazione dovresti ancora codificare quella parte, ma puoi farlo nelleditor in cui scrivi il codice e, cosa più importante: il framework stesso del sistema di compilazione di solito fornisce un supporto per lorganizzazione di questi script.

Infine, i sistemi di compilazione sono utili per qualcosa di più della semplice costruzione del progetto: puoi programmarli per svolgere altre attività che tutti i membri del team potrebbero dover svolgere. In Ruby su Rails , ad esempio, ci sono attività di sistema di compilazione per eseguire migrazioni di database, per pulire i file temporanei, ecc. Mettere queste attività nel sistema di compilazione garantisce che tutti i membri del team possano eseguirle in modo coerente.

Commenti

• ‘ non è solo una questione di IDE diversi. Alcuni sviluppatori odiano e detestano IDE di tutti i tipi.
• @DavidHammen Sono ‘ uno di questi sviluppatori (anche se ‘ ho configurato il mio Vim così difficile ‘ è possibile che io labbia trasformato in un IDE …), e mentre scrivevo quel paragrafo scrivevo automaticamente ” editors ” e ho dovuto aggiustarlo su IDE, perché penso che il dispositivo sugli IDE sia una parte importante della mia risposta. Il richiedente proviene chiaramente dal mondo degli IDE e la domanda parla dello sviluppo senza IDE come qualcosa che sei costretto a fare quando non è disponibile un IDE appropriato. Il punto di questa risposta è mostrare come i sistemi di compilazione siano vantaggiosi anche per i team composti esclusivamente da utenti IDE.
• Anchio sono uno di quegli sviluppatori. ‘ non voglio che le mie dita debbano lasciare la tastiera. Ciò interrompe i miei processi mentali.
• Non sono daccordo. Preferisco gli IDE. Mi permettono di non preoccuparmi dei nomi, delle ricerche facili, del refactoring, dellinterfaccia utente piacevole. Voglio dire, se un IDE può fare qualcosa per me che altrimenti farei con sed ack ecc., Lo uso.
• Il punto è che con gli script di build ogni sviluppatore del team può usare quello che preferisce, mentre con la funzionalità di build dellIDE ‘ stai costringendo tutti non solo a usare un IDE, ma anche a usare lIDE molto specifico per cui è configurato il progetto (a meno che tu non lo abbia configurato per più IDE e buona fortuna per la sincronizzazione …)

Molti IDE semplicemente impacchettano i comandi utilizzati per creare qualcosa e quindi generare uno script e chiamarlo!

Ad esempio, in Visual Studio, puoi vedere i parametri della riga di comando per una compilazione C ++ nella casella “riga di comando”. Se osservi attentamente loutput di build, vedrai il file temporaneo che contiene lo script di build utilizzato per eseguire la compilazione.

Al giorno doggi, è tutto MSBuild , ma è ancora eseguito direttamente dallIDE.

Quindi il motivo per cui usi la riga di comando è che vai direttamente al sorgente e salti lintermediario, un intermediario che potrebbe essere stato aggiornato o richiedere un mucchio di dipendenze che semplicemente non desideri o non ti servono su un server headless che funge da integrazione continua (CI) server.

Inoltre, i tuoi script fanno più dei soliti passaggi orientati allo sviluppatore per cui sono stati progettati.Ad esempio, dopo una compilazione, potresti volere che i tuoi binari vengano impacchettati e copiati in una posizione speciale, o che venga creato un pacchetto di installazione o che su di essi venga eseguito uno strumento di documentazione. Molte attività diverse vengono eseguite da un server CI che sono inutili su una macchina per sviluppatori, quindi mentre si potrebbe creare un progetto IDE che ha eseguito tutti questi passaggi, è necessario mantenerne due: un progetto per sviluppatori e un altro per build. Alcune attività di compilazione (ad esempio lanalisi statica) possono richiedere molto tempo che non vorresti per i progetti degli sviluppatori.

In breve, però, è semplicemente più facile: crea uno script per fare tutte le cose che è veloce e semplice da avviare dalla riga di comando o dalla configurazione di un server di compilazione.

make 

è molto più facile da ricordare e digitare che

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 compilazione ha anche la capacità di ricompilare solo le cose che sono cambiate. Se vuoi creare una build pulita,

make clean 

è più facile e più affidabile una volta impostato correttamente che cercare di ricordare ogni singola posizione che un file intermedio può avere stato prodotto.

Ovviamente, se usi un IDE, anche fare clic su un pulsante build o clean è facile. Tuttavia, è molto più difficile automatizzare lo spostamento del cursore in un punto specifico dello schermo, specialmente quando quel punto può spostarsi se la finestra si sposta, piuttosto che automatizzare un semplice comando di testo.

In quale altro modo lo faresti? Lunico altro modo è specificare un lungo comando della riga di comando.

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

I makefile possono anche rendere multipiattaforma un processo di compilazione. 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 allIDE. Lo fanno perché vogliono il potere di questi gli editor forniscono. Gli script di compilazione sono necessari per coloro che non utilizzano un IDE.

Anche per coloro che utilizzano un IDE, potresti voler sapere veramente cosa sta succedendo, quindi lo script di compilazione ti offre i dettagli più bassi di implementazione che un approccio GUI non ha.

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

Le risposte precedenti coprono molte buone basi, ma un esempio del mondo reale che vorrei aggiungere (che non posso “aggiungere come commento a causa dellassenza di karma), proviene dalla programmazione Android.

Sono un professionista Android / iOS / Windows Sviluppatore di telefoni e utilizzo le API dei servizi Google (principalmente Google Maps) un lot .

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

Invece di aggiungere e gestire una dozzina di keystore alla console per sviluppatori, solo uno dei quali può essere effettivamente utilizzato per aggiornare lapp comunque, includo questo keystore nel nostro repository sicuro e usa Gradle per dire ad Android Studio esattamente quale keystore usare durante la creazione per “debug” o “release”. Ora devo solo aggiungere due keystore alla mia console per sviluppatori Google, uno per “debug” e uno per “release”, e tutti i membri del mio team possono clonare il repository e iniziare lo sviluppo senza dover accedere allo sviluppo console e aggiungere lhash SHA del loro particolare keystore, o peggio, facendomi gestire . Ciò ha lulteriore vantaggio di fornire a ciascun membro del team una copia del keystore di firma, il che significa che se sono fuori ufficio ed è pianificato un aggiornamento, un membro del team deve solo seguire un elenco molto breve di istruzioni per inviare un aggiornamento.

Lautomazione della creazione come questa mantiene le build coerenti e riduce il debito tecnico riducendo i tempi di configurazione quando otteniamo un nuovo sviluppatore, una nuova macchina o quando dobbiamo ricreare unimmagine macchina.

Vantaggi dello script di creazione:

• le modifiche sembrano codice (per 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 utilizzato gli script di build per:

• generare la documentazione del progetto (basata su doxygen)
• build
• eseguire unit test
• generare rapporti sulla copertura di unit test
• comprimere i file binari in un archivio di rilascio
• generare note di rilascio interne (in base ai messaggi “git log” )
• test automatizzato

Spesso puoi chiamare il pulsante “build” in modo automatizzato (Visual Studio accetta argomenti della riga di comando, ad esempio). 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 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ò raggrupparli tutti in un pacchetto di installazione?