Tomcat + Spring + CI flusso di lavoro [chiuso]

Question

Tomcat + Spring + CI flusso di lavoro [chiuso]

#1 da (1 voti)

1

Stiamo iniziando il nostro primo progetto con Spring e java stack web. Questo progetto riguarderà principalmente la riscrittura di un ERP / CRM piuttosto ampio da Zend Framework a Java . Un fattore importante nella mia domanda è che provengo da php territorio, dove le cose (in termini di qualità) tendono ad apparire diverse rispetto a java world.

Fatcs :

ci saranno 2-3 sviluppatori,
almeno uno degli sviluppatori usa Windows, resto usa Linux,
c'è una macchina remota basata su Linux, che dovrebbe gestire le istanze di test e produzione,
dopo aver lottato con il codice legacy buggy, vogliamo introdurre buone pratiche di programmazione e sviluppo (CI, test, codice pulito e così via)
client: modifiche logiche interne e frequenti,
mischia, schieramenti giornalieri

Quello che voglio ottenere è un buon flusso di lavoro sul maggior numero possibile di fasi di sviluppo (coding - > commiting - > testing - > deploying). Il problema è che non l'ho mai fatto prima, quindi non so quali sono le migliori pratiche per farlo.

Quello che ho finora è:

codice degli sviluppatori localmente,
c'è un'istanza di vagrant su ogni macchina di sviluppo, gestita da puppet . Contiene le stesse linux , jenkins e tomcat versioni come macchina di produzione,
durante la codifica, lo sviluppatore si distribuisce alla macchina vagabonda,
dopo l'unione locale al ramo test , jenkins ai test degli handle vagabondi,
quando tutto va bene, lo sviluppatore spinge il commit e si unisce
jenkins sulla macchina remota richiama il commit da test branch, esegue test e così via,
se tutto sembra verde, jenkins distribuisce a test tomcat istanza
La distribuzione in produzione è manuale (anche se può essere eseguita utilizzando gli script di aiuto) quando la logica di business viene testata da altre divisioni e tutto sembra a posto per il cliente.

Ora, la vera domanda: sopra ha senso? Cose di cui non sono sicuro:

Macchina remota: non ci saranno problemi con due (o anche tre, come potrebbe essere necessario a Jenkins) istanze della stessa app su tomcat ?
Usare vagrant per svilupparsi su php environment è solo una morsa. Non è questo eccessivo utilizzo durante l'utilizzo di Tomcat? Voglio dire, c'è una maggiore probabilità che tomcat agisca allo stesso modo su ogni macchina?
C'è la sensazione di avere jenkins locale su vagabondo?

java workflows continuous-integration virtualization jenkins

posta ex3v 22.08.2014 - 16:02

fonte

1 risposta

Leggi altre domande sui tag java workflows continuous-integration virtualization jenkins

Esecuzione di una profondità Prima Cerca in modo iterativo utilizzando l'elaborazione asincrona / parallela? Utilizzo di un elenco di tuple vs un elenco di oggetti personalizzati

score 1 · Accepted Answer

Benvenuti nel mondo di CI! (Posso suggerire questo libro ? Mi ha davvero aiutato a capire come funziona questa pratica della CI)

Remote machine: won't there be any problems with two (or even three, as jenkins might need one) instances of same app on tomcat?

Nella mia esperienza: Sì. Ma sono sicuro che sono causati dalla mia mancanza di conoscenza / esperienza. Il mio ambiente di test è un vecchio computer scadente e le risorse di sistema sono scarse. Ho automatizzato quasi tutti i passaggi da git push alla distribuzione delle app, ma di tanto in tanto alcuni .jar non vengono rilasciati da Tomcat e ottengo errori di memoria dalle mie build su Jenkins. (Sono già stato qui , qui , qui , qui e anche qui ). Probabilmente potresti dover configurare il tuo progetto Jenkins in modo tale da poter annullare la distribuzione dell'app corrente in esecuzione su Tomcat, riavviare Tomcat, crearne uno nuovo e distribuire quella nuova build.

Using vagrant to develop on php environment is just vise. Isn't this overkill while using Tomcat? I mean, is there higher probability that tomcat will act the same on every machine?

Dopo aver letto il libro che ho menzionato, sembra che lo scenario migliore sarebbe che ogni sviluppatore dovrebbe eseguire jenkins e tomcat sulle proprie macchine, compilare e distribuire solo con le loro modifiche (dopo aver superato i test, ovviamente) e poi spingere le modifiche al repository comune in cui i test verranno eseguiti di nuovo insieme alle modifiche di tutti gli altri e l'app verrà costruita e implementata in produzione / test. Non riesco a pensare a nessun caso in cui un'app venga eseguita su un'istanza di tomcat in una macchina e si blocca su un'altra, ma poi ricorda ancora la mia mancanza di conoscenza.