Suggerirei di utilizzare Maven anziché Ant. 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 distributore localmente significa che devi distribuire manualmente quello distribuibile sul tuo sistema di produzione, e implica che probabilmente hai dovuto fare un bel po 'di configurazione manuale sul sistema di produzione per prepararlo alla distribuzione (installazione di Tomcat , forse, o copiando le dipendenze e le risorse richieste dalla tua applicazione). Questo può richiedere molto tempo e potrebbe rendere la distribuzione degli aggiornamenti un processo noioso e manuale. Inoltre, consente di individuare eventuali differenze di configurazione minori tra la piattaforma di produzione e l'ambiente di sviluppo, causando errori oscuri e difficili da rintracciare.

In ogni caso, ciò che faccio per eliminare questo lavoro manuale è che configuro il mio progetto da creare con Maven e configuro il mio file pom.xml con tutte le informazioni richieste (nel caso di un web Java app) trova e scarica la versione corretta di Tomcat, la installa in locale, imposta i file di configurazione di Tomcat corretti, distribuisce tutte le dipendenze del progetto e il file WAR di progetto stesso, quindi avvia Tomcat. Creo quindi un semplice script shell (e anche una versione .bat per Windows) che utilizza Maven per creare e avviare il server:

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

Quindi, invece di impacchettare un deployable sul mio ambiente dev e poi spingerlo manualmente in produzione, tutto ciò che devo fare è sincronizzare dal sistema di controllo della versione sul server di produzione, e quindi il sistema di produzione stesso crea, installa , ed esegue il deployable (e lo fa in un modo che è identico a come è fatto su qualsiasi sistema di sviluppo, minimizzando la possibilità di errori specifici della piattaforma o errori di configurazione). E se nello sviluppo o nell'ambiente 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. Interrompi l'istanza del server in esecuzione, se presente.
2. Esegui svn update -r<target_release_revision> .
3. Esegui ./startServer.sh .

È semplice, facile da ricordare, e non è assolutamente possibile farlo se dovessi fare affidamento sull'uso del mio IDE per costruire il deployable per me. Rende anche istantaneo il ritorno all'ultima distribuzione nota, qualora fosse necessario un rollback.

Non riesco nemmeno a contare il tempo impiegato da questo approccio per tentare di gestire manualmente il processo di distribuzione e configurazione.

Ovviamente, un'altra risposta alla tua domanda è la gestione automatica delle dipendenze, ma credo che sia già stata trattata da altre risposte.

Finché il tuo codice è nel controllo del codice sorgente, usare l'IDE per rendere i tuoi prodotti distribuibili va bene.

Come negozio di un solo uomo, è meglio spendere il tuo tempo aggiungendo nuove funzionalità al tuo prodotto o scrivendo script di compilazione? Qualcosa mi dice che non scrive script di compilazione.

Certo, è più difficile vedere i benefici quando lavori da solo. Personalmente, ho lavorato a molti progetti solisti e non solo scriverei uno script di costruzione, 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 viene eseguito da un server di build, è possibile eseguirlo da altre macchine.
• Il divertimento inizia dopo la costruzione e il test delle unità (a proposito: sei sicuro test prima di ogni commit? 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 grafici di copertura del codice, guasti ai test delle unità, ecc. nel tempo. Il tuo IDE lo fa?

Per il mio progetto corrente, lo script costruisce, 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 test.

Mi sono preso il tempo per impostare questo (lo script di compilazione è forse 300 righe a proposito, non l'ho toccato in 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 creazione / distribuzione consiste nei comandi "hg commit" e "hg push".

Vantaggi degli strumenti di creazione

È un breve riassunto che mostra solo la punta dell'iceberg, e non noterai necessariamente l'importante di tutto questo a meno che tu non abbia bisogno di fare una combinazione di molti progetti, grandi progetti e team medio-grandi. Ma se hai fede e prova, ottieni i vantaggi .

Facilitano il ciclo di vita dello sviluppo e consentono di:

• organizza e struttura i tuoi progetti coerentemente e senza sforzo
• riutilizzare buone pratiche su tutti i progetti e facilmente e rapidamente kick-start ,
• integri più projets in una singola build,
• automatizza il tuo processo di integrazione continua ,
• condividi il tuo progetto con gli altri
  • senza imporre loro di utilizzare uno specifico toolkit o IDE (a parte il sistema di compilazione),
  • e senza sorprenderli poiché si aspettano una build standard
• automatizza e facilita la manutenzione del tuo prodotto
• automatizza il processo di rilascio del tuo prodotto

Se lo applichiamo a Maven ...

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

• La convenzione del progetto strutturato di Maven
• Maven Archetypes
• Materializzazione di un progetto da SCM e build di reattori
• Jenkins / Hudson / Bamboo / altro supporto + Supporto di Maven per le 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 plug-in e versioni-maven-plugin

E ovviamente Maven (ma anche altri strumenti) ti dà la gestione delle dipendenze , e questo è un enorme tempo e spazio risparmiatore per te (calcolato per il numero di persone nel tuo team) e il tuo SCM.

Tutto relativo:

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

Ecco i miei 4 principali motivi per utilizzare gli strumenti di creazione:

• gestione delle dipendenze (evitare errori)
• testing (la tua modifica non ha infranto altri moduli - molto più facile da testare)
• sicurezza commette
• più facile da distribuire distribuibile localmente (nessuno ha tempo in QA env per aspettare che il builder costruisca il tuo progetto e le sue dipendenze)

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

I even have a potential investor lined up and plan to show them a beta version in the next few weeks

Quindi, sono certo che il tuo team crescerà ... È ancora più importante avere abilità di test-deploy automatico fatte.

Il grande XML (script) che hai visto, è in genere un lavoro singolo. La maggior parte delle volte, gli stessi script possono essere utilizzati su molti progetti.

Non è chiaro quanto è grande il progetto. Se i test integrati / test di accettazione richiedono una grande CPU / memoria, si può considerare l'utilizzo di un'altra macchina come server di prova. Puoi anche distribuire host di strumenti per analizzare il codice sorgente / byte codice .

Direi che, per uno sviluppatore solitario, avere un buon processo e una struttura simile a quella degli script è molto più importante di quando si è in una squadra. La ragione è che non hai compagni di squadra che ti chiamano quando tagli gli angoli. Un server CI che esegue il tuo script di build è un ottimo compagno di squadra senza compromessi per mantenerti onesto.

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

Una build non IDE semplifica la ricostruzione di vecchie versioni senza doversi preoccupare di riconfigurare l'IDE nel modo in cui era in quel momento, consente di eseguire la build in modo non interattivo in modo da poter mantenere una build notturna per le persone da testare, oppure scoprire rapidamente se si sono interrotte le prove senza dover ricordare di eseguirle e attendere che si completino.

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

Alcuni strumenti di sviluppo ti aiutano ad automatizzare la codifica e la distribuzione di versioni, sono dotati di valori di default decenti per generare rapporti sulla copertura del codice, ecc.

Quando aggiungi più persone, uno strumento di costruzione assicurerà che tu non sia vulnerabile alla scarsa configurazione IDE di qualcun altro. Faccio regolarmente screenshot per correggere le installazioni di Eclipse dei colleghi perché non usano strumenti di compilazione (lavorando su quello).

La ragione ultima però è che è qualcosa che non ha bisogno di essere fatto manualmente, quindi non farlo manualmente. Tutto il resto cade fuori da quello.