Come organizzare la pipeline completa di build con Gulp, Maven e Jenkins, fino ai test di integrazione?

Question

Ho un progetto che ha:

• client JS con processo di generazione un po 'interessante. Ciò include la compilazione di CSS, la catenazione e la minimizzazione di JS e CSS, la generazione e l'elaborazione di HTML e altri passaggi. Gli strumenti Node come Grunt o Gulp sono fantastici in questo.
• Server Java che è un WAR distribuito su Tomcat. Include queste risorse e tutto il codice Java. Ha tutti i tipi di test: test unitari, test di integrazione che possono istanziare un DAO e parlare con DB e test API end-to-end che parlano effettivamente con l'app in esecuzione su Tomcat.
• Test end-to-end con goniometro. Se non ti è familiare, è un altro strumento di nodo che avvolge il selenio.

Come posso organizzare l'intero processo in modo sano, solido e automatizzato?

Quello che ho al momento è Gulp e Maven, con Maven che possiede praticamente l'intero processo.

1. Si chiama Gulp asset generation in generate-sources utilizzando antrun (doh, terzo strumento di compilazione!).
2. Esegue la normale versione di Java.
3. Avvia Tomcat con il mio WAR nel test di pre-integrazione.
4. Esegue test E2E Java che parlano con quel tomcat con plug-in failsafe.
5. Chiama nuovamente Gulp con antrun, questa volta per eseguire i test del goniometro.
6. Arresta Tomcat nel test di post-integrazione.
7. Si suppone che verifichi i risultati del test in fase di verifica.

Questo tipo di opere, tranne che per Maven è generalmente molto rigido e sento che sto prendendo troppo lontano. Usare antrun per chiamare Gulp è un brutto trucco. È molto difficile controllare le dipendenze tra questi passaggi e monitorare i loro risultati. È difficile controllare l'ordine delle cose nella stessa fase. La verifica di sicurezza non sembra elaborare i file di report JUnit esterni generati da Gulp. Potrei andare avanti

Mi chiedo se dovrei fare di più nel mio server di build (Jenkins), magari usando una pipeline di build o trigger parametrizzati - ma non l'ho mai fatto e non sono sicuro che sia davvero meglio.

Quindi, come lo implementeresti?

Answer 1

Cercherei di costruire una sorta di conduttura di uomo povero.

1. Let grugnito/sorso fare il suo lavoro prima (asset dei processi, i test eseguiti frontend ecc - si preparano manufatti da inserire in guerra). Fallisce l'intera build quando questo passaggio non riesce (generazione di risorse o test).

2. Esegui una build generica di Maven che produce un file WAR con le risorse create nel passaggio 1. Esegue il proprio set di test con un file WAR normale. Non ha bisogno di sapere cose grunt/gulp.

Avrai quindi due posizioni, ad es.i test vengono eseguiti (frontend, eseguiti da grunt/gulp e backend da parte di Maven) ma la configurazione dei reporter corretti permetterà ai server CI di rilevarli tutti (usiamo TeamCity e lo gestisce bene).

Scriptarlo un po 'e dovrebbe essere meglio che chiamare il nodo via antrun più volte. In alternativa puoi eseguire il primo passaggio dall'interno di Maven, ma potrebbe essere difficile controllare le cose.

Answer 2

In base alla mia esperienza, il plugin di frontend maven è di gran lunga il miglior plug-in per questo tipo di processo di build/deploy. https://github.com/eirslett/frontend-maven-plugin. Questo è il modo in cui lo uso per Grunt ma supporta anche Gulp.

<plugin> 
    <groupId>com.github.eirslett</groupId> 
    <artifactId>frontend-maven-plugin</artifactId> 
    <version>...</version> 

    <!-- optional --> 
    <configuration> 
     <workingDirectory>src/main/frontend</workingDirectory> 
    </configuration> 

    <execution> 
    <id>grunt build</id> 
    <goals> 
     <goal>grunt</goal> 
    </goals> 

    <!-- optional: the default phase is "generate-resources" --> 
    <phase>generate-resources</phase> 

    <configuration> 
     <!-- optional: if not specified, it will run Grunt's default 
     task (and you can remove this whole <configuration> section.) --> 
     <arguments>build</arguments> 
    </configuration> 
</execution> 
</plugin> 

Una cosa da tenere presente è scaricherà nodo per il sistema è in esecuzione su, quindi se avete un sistema operativo diverso sul server di build, avrete bisogno di fare in modo che è la versione hai controllato il controllo della versione, la tua versione locale (per me OSX) dovrà essere mantenuta locale per il tuo progetto.

Answer 3

Ho appena intenzione di usare questo come uno stub perché ho cercato di fare una cosa simile, e tornerò più tardi per arricchire la mia risposta. Nel frattempo dovresti cercare JHipster. Anche se hanno uno stack molto più grande, e il loro stack è già stato creato, stanno essenzialmente facendo ciò che penso che vogliano nel loro processo di compilazione.

Anche se non sono completamente d'accordo con il loro processo di costruzione, tornerò per spiegare perché e cosa sto facendo nei progetti su cui sto lavorando attualmente.

Answer 4

Questo progetto ha circa 2 anni ma fa molto di quello che stai cercando.

https://github.com/pankajtandon/PointyPatient/blob/master/pointy-web/pom.xml

fare cassa il pom madre che gestisce praticamente tutti i sotto-progetti insieme proprio dal web al dominio per il pronti contro termine e non riesce se qualsiasi (Jasmine o SpringMVC o SpringServices test) sicuro. E costruisce una guerra anche per la distribuzione lato server.

Questo era il pre-goniometro, quindi sarebbe una bella aggiunta. Anche il plugin di frontend maven sembra ora lo strumento per il lavoro.

HTH Pankaj