Durante i miei anni di programmazione Java e più recentemente Scala, non ho mai usato Ant, Maven, Gradle o nessuno di quegli strumenti di costruzione per Java. Ovunque abbia lavorato c'era un responsabile della costruzione che si occupava di tutto ciò: compilavo localmente con l'IDE per lo sviluppo e il testing delle unità, quindi controllavo il codice sorgente e avvisavo il responsabile della costruzione che faceva ciò che era necessario compilare i file di tutti per l'ambiente condiviso.

Ora che sono tra i contratti ho lavorato sul mio progetto autofinanziato e sta arrivando al punto in cui potrebbe essere abbastanza buono per fare effettivamente soldi. Ho anche un potenziale investitore in fila e ho intenzione di mostrargli una versione beta nelle prossime settimane.

Ma sempre clicco sul pulsante build sull'IDE, e crea il file Jar e funziona perfettamente. Naturalmente, la saggezza convenzionale suggerisce che "dovrei" scrivere i miei script Ant / Maven / Gradle e usarli al posto dell'IDE, ma quali sono i vantaggi concreti di questo nella mia situazione (lavorare da solo)?

Ho fatto alcune letture su come usare quegli strumenti di compilazione, e sembra che stia scrivendo centinaia di righe di XML (o Groovy o qualsiasi altra cosa) per fare ciò che l'IDE fa con un clic (generato dall'IDE Ant XML per il progetto è oltre 700 linee). Sembra solo soggetto a errori e richiede tempo e non è necessario per la mia situazione. Per non parlare della curva di apprendimento, che toglierebbe tempo a tutto il resto del lavoro che sto facendo per preparare il prodotto a mostrare alla gente.

Suggerirei di esaminare l'utilizzo di Maven invece della formica. Se il tuo IDE può costruire il tuo progetto in un clic, è probabile che Maven possa anche costruire il tuo progetto praticamente senza alcuna configurazione personalizzata.

E per rispondere alla domanda, semplificare il processo di distribuzione è un esempio concreto. Se stai costruendo un distribuibile localmente ciò significa che devi distribuirlo manualmente sul tuo sistema di produzione e implica che probabilmente hai dovuto fare un bel po 'di configurazione manuale sul sistema di produzione per prepararlo per la distribuzione (installazione di Tomcat , forse, o copia su dipendenze e risorse richieste dall'applicazione). Ciò può richiedere molto tempo e può rendere la distribuzione degli aggiornamenti un processo noioso e manuale. Consente inoltre il potenziale per eventuali differenze di configurazione minori tra la piattaforma di produzione e l'ambiente di sviluppo che causano errori oscuri, difficili da rintracciare.

Quindi, comunque, ciò che faccio per sbarazzarmi di questo lavoro manuale è che configuro il mio progetto per la compilazione con Maven e configuro il mio pom.xmlfile con tutte le informazioni necessarie per (nel caso di un'app Web Java) trovare e scaricare il versione corretta di Tomcat, installarlo localmente, impostare i file di configurazione Tomcat corretti, distribuire eventuali dipendenze del progetto e il file WAR del progetto stesso, quindi avviare Tomcat. Quindi creo un semplice script di shell (e anche una .batversione per Windows) che utilizza Maven per compilare e avviare il server:

mvn clean install cargo:start -Dcargo.maven.wait=true

Quindi, invece di impacchettare un distribuibile nel mio ambiente di sviluppo e poi inviarlo manualmente alla produzione, tutto ciò che devo fare è sincronizzare dal sistema di controllo della versione sul server di produzione, quindi il sistema di produzione stesso crea, installa ed esegue lo schierabile (e lo fa in modo identico a come viene fatto su qualsiasi sistema di sviluppo, riducendo al minimo la possibilità di errori specifici della piattaforma o configurazioni errate). E sia nell'ambiente di sviluppo che in quello di produzione, tutto ciò che faccio per creare e avviare il server è:

./startServer.sh #or startServer.bat for Windows

E per distribuire un aggiornamento all'ambiente di produzione il processo è solo:

1. Arresta l'istanza del server in esecuzione, se presente.
2. Corri svn update -r<target_release_revision>.
3. Corri ./startServer.sh.

È semplice, facile da ricordare e non è affatto possibile fare se dovessi affidarmi all'utilizzo del mio IDE per creare il deployable per me. Rende inoltre il ripristino dell'ultima implementazione nota nota in un attimo, qualora fosse necessario un rollback.

Non riesco nemmeno a contare il tempo che questo approccio mi ha risparmiato rispetto al tentativo di gestire manualmente il processo di distribuzione e configurazione.

E, naturalmente, un'altra risposta alla tua domanda è la gestione automatica delle dipendenze, ma credo che sia già stato coperto da altre risposte.

Finché il tuo codice è nel controllo del codice sorgente, l'utilizzo dell'IDE per rendere i tuoi distributori va bene.

Come one man shop, il tuo tempo è speso meglio aggiungendo nuove funzionalità al tuo prodotto o scrivendo script di build? Qualcosa mi dice che non sta scrivendo script di compilazione.

Certo, è più difficile vedere i benefici quando lavori da solo. Personalmente, ho lavorato su molti progetti solisti e non solo avrei scritto uno script di build, ma ho anche avuto il problema di configurare un server CI (come Jenkins).

Ovviamente c'è un sovraccarico, perché ne varrebbe la pena?

• Una build riproducibile, non legata all'IDE (o alla tua macchina, se la esegui esternamente). Se un server di build lo esegue, altri computer possono eseguirlo.
• Il divertimento inizia dopo la costruzione e il collaudo delle unità (a proposito: sei sicuro di provare prima di ogni impegno? A volte dimentico). Genera documentazione, crea programmi di installazione, esegui i tuoi strumenti di analisi del codice preferiti.
• Il tuo server CI preferito ti consente di visualizzare nel tempo grafici di copertura del codice, guasti ai test unitari, ecc. Il tuo IDE lo fa?

Per il mio progetto attuale, lo script crea, esegue strumenti di analisi statica, comprime js / css, unit test e pacchetti in un archivio web. Jenkins lo esegue dopo ogni commit e distribuisce il progetto su un server di prova.

Mi sono preso il tempo di impostare questo (lo script di build è forse di 300 righe tra l'altro, non l'ho toccato da mesi) e posso dire che ne vale la pena, anche per una persona. Per più di una persona, è necessario. Il mio coinvolgimento nel processo di compilazione / implementazione consiste nei comandi "hg commit" e "hg push".

Vantaggi degli strumenti di costruzione

È un breve riassunto che mostra solo la punta dell'iceberg e non noterai necessariamente l'importanza di tutto ciò a meno che tu non debba fare con una combinazione di molti progetti, progetti di grandi dimensioni e team medio-grandi. Ma se hai fede e prova, ne trarrai beneficio .

Semplificano il ciclo di vita dello sviluppo e consentono di:

• organizzare e strutturare i progetti in modo coerente e senza sforzo
• riutilizzare le buone pratiche tra i progetti e avviarle facilmente e rapidamente ,
• integrare più progetti in una singola build,
• automatizzare il processo di integrazione continua ,
• condividi il tuo progetto con gli altri
  • senza obbligarli a utilizzare uno specifico toolkit o IDE (a parte il sistema di compilazione),
  • e senza sorprenderli perché si aspetteranno una build standard
• automatizzare e facilitare la manutenzione del prodotto
• automatizzare il processo di rilascio del prodotto

Se lo applichiamo a Maven ...

Per quelli di voi nel mondo Java e che usano Maven , leggendo questo avete naturalmente associato ogni punto a:

• La convenzione di progetto strutturato di Maven
• Archetipi di Maven
• Materializzare un progetto da SCM e build di reattori
• Jenkins / Hudson / Bamboo / altro supporto + Supporto di Maven per pratiche di test di integrazione
• m2eclipse, supporto nativo IntelliJ o NetBeans - o mvnsh per la riga di comando
• versioni-maven-plugin
• maven-release-plugin, buildnumber-maven-plugin plugin e versioni-maven-plugin

E, naturalmente, Maven (ma anche altri strumenti) ti offre la gestione delle dipendenze , e questo è un enorme risparmio di tempo e spazio per te (tenuto conto del numero di persone nel tuo team) e del tuo SCM.

Tutto è relativo:

Sto usando Maven come esempio perché penso che sia il sistema di costruzione più completo e "batterie incluse", ma non significa che sia necessariamente il "migliore". Si adatta comunque a tutte le caselle sopra elencate e, quando cerco un buon sistema di build, lo confronto con questo elenco e Maven. Tuttavia, Maven non è sempre molto flessibile - è comunque molto estensibile - se si discosta dal processo standardizzato. Aumenta la tua produttività nel caso generale (una volta davanti alla curva di apprendimento), non se la combatti.

Ecco i miei 4 principali motivi per usare gli strumenti di costruzione:

• gestione delle dipendenze (evitare errori)
• test (la modifica non ha interrotto altri moduli - molto più facile da testare)
• si impegna in sicurezza
• più facile da distribuire distribuibile localmente (nessuno ha tempo in QA env per attendere che il costruttore costruisca il tuo progetto e le sue dipendenze)

Nel libro Pragmatic Programmer , Andrew Hunt e David Thomas affermano che "checkout-build-test-deploy" dovrebbe essere un singolo comando (Capitolo: Pragmatic Projects). Hai scritto..

Ho anche un potenziale investitore in fila e ho intenzione di mostrare loro una versione beta nelle prossime settimane

Quindi, sono sicuro che il tuo team crescerà .. È ancora più importante che vengano completate le funzionalità di distribuzione automatica dei test.

Il grande XML (script) che hai visto, è in genere un lavoro una tantum. Il più delle volte, gli stessi script possono essere utilizzati in molti progetti.

Non è chiaro quanto sia grande il progetto. Se i test integrati / test di accettazione richiedono CPU / memoria di grandi dimensioni, è possibile utilizzare un altro computer come server di test. È inoltre possibile distribuire host di strumenti per analizzare il codice sorgente / codice byte .

Direi che, per uno sviluppatore solitario, avere un buon processo e una struttura come build con script è enormemente più importante di quando si fa parte di una squadra. Il motivo è che non hai compagni di squadra per chiamarti quando tagli gli angoli. Un server CI che esegue il tuo script di build è un compagno di squadra senza compromessi che ti rende onesto.

Man mano che la tua base di codice cresce, vorrai aggiungere una suite di test. La mia esperienza è che questo dovrebbe essere fatto prima piuttosto che dopo e che la tua build notturna (o qualunque cosa) dovrebbe eseguire tutti i test ogni volta. Inizia in piccolo, l'XML generato automaticamente probabilmente va bene. Quando hai paura di cambiare qualcosa per paura di rompere qualcos'altro, è un buon incentivo a scrivere alcuni casi di prova.

Una build non IDE semplifica la ricostruzione di vecchie versioni senza preoccuparsi di riconfigurare il tuo IDE come era in quel momento, ti consente di eseguire la build in modo non interattivo in modo da poter mantenere una build notturna per le persone da testare o scoprirla rapidamente se hai superato i test senza dover ricordare di eseguirli e attendere che vengano completati.

Inoltre, ti consente di eseguire build in ambienti non con GUI, ad esempio ssh'ing su un server, e ti consente di cambiare IDE senza preoccuparti di perdere la capacità di creare il tuo software.

Alcuni strumenti di compilazione ti aiutano ad automatizzare la codifica e la distribuzione di rilasci, presentano valori predefiniti decenti per la generazione di rapporti sulla copertura del codice, ecc.

Quando aggiungi più persone, uno strumento di compilazione ti assicurerà di non essere vulnerabile alla scarsa configurazione IDE di qualcun altro. Faccio regolarmente schermate per riparare le installazioni di Eclipse dei colleghi perché non usano strumenti di compilazione (lavorando su quello).

Il motivo ultimo però è che è qualcosa che non deve essere fatto manualmente, quindi non farlo manualmente. Tutto il resto ne esce.