Creazione di rapporti sullo stato del progetto javascript

2

Ho un progetto javascript che utilizza Grunt e diversi plug-in come:

Non tutti gli sviluppatori eseguono le attività grunt localmente (ad es. jshint, qunit), quindi potrebbero non sapere se il codice che hanno commesso presenta problemi. È abbastanza facile impostare un'attività di watch grunt, ma inviare email al team in caso di errore / avvertimento è stato meno ovvio di quanto mi aspettassi.

Mi aspettavo di trovare qualcosa come grunt-contrib-emailstatus per inviare via email uno stato ben formattato, ma finora non ho trovato questo. Mi è mancato?

In caso contrario, qual è la pratica consigliata qui? In passato ho visto cose come Cruise Control, Jenkins o Hudson gestire i rapporti sullo stato delle build, ma sembra un martello troppo grande per questo chiodo. E d'altra parte, provare a utilizzare crontab per inviare lo stato di email sembra troppo piccolo.

    
posta explunit 06.06.2013 - 21:02
fonte

1 risposta

1

Quello che ho fatto nella mia squadra è:

  • Usiamo git , quindi ho impostato un hook di commit git. Quindi ogni volta che impegni Grunt esegue jshint. Se fallisce, non puoi impegnarti.

    • Buono : un sacco di volte mi sono dimenticato di eseguire jshint a mano. Quindi un errore di commit è il miglior promemoria.
    • Non valido : aggancio commit significa: commit al tuo repository git (non ricevendo una push sull'origine). Quindi è necessario impostare il commit hook localmente (ho creato un task grunt per questo). Per questo l'efficacia dell'approccio dipende dall'onestà di ogni sviluppatore (anche tu puoi forzare il commit senza eseguire gli hook). Un altro problema: se si utilizza un'interfaccia utente Git, è necessario configurare correttamente il PERCORSO affinché il programma possa eseguire il commit hook senza errori. Ma impostare PATH per l'interfaccia utente in MacOSX non è così semplice (molte modifiche in quell'area tra le versioni MacOSX)
  • Usiamo Jenkins. Quindi la compilazione fallisce se jshint o il test dell'unità falliscono. Sì, è un "grosso martello", ma questi strumenti sono progettati per quel tipo di attività di integrazione continua. Puoi usarli per altri tipi di cose come creare il tuo bundle di produzione, o fare alcuni test funzionali usando veri browser web. Ad esempio, utilizziamo Jenkins ospitato su Cloudbees e attiviamo alcuni test funzionali basati su SauceLabs.

Inoltre è possibile impostare un hook di commit lato server. Non potrei farlo poiché usiamo Github e non controlliamo il server git (Github offre tale funzionalità collegando le app di terze parti al repository, come Travis CI).

Ma se controlli il tuo repository git e non vuoi usare un grande strumento CI, puoi impostare un hook post-ricezione che ( link ) che attiva la verifica in background e invia l'e-mail (in pratica si sta scrivendo uno strumento CI di home-brew in quel caso; ))

    
risposta data 14.09.2013 - 18:09
fonte