Newsgroup: it.comp.java
Titolo: Progetto Java

Vorrei sottoporre alla vostra attenzione la seguente domanda:
Qual è il modo “migliore” per gestire il lavoro in Team in un progetto Web
di portata Enterpise ?
Formulando un’ipotesi:
5 Sviluppatori ed un server di test:
Ambiente di sviluppo: Jbuilder
Application Server: WebLogic
Le problematiche riguardano i capisaldi relativi a:
1) Allineamento del codice.
2) Debug.
3) Deploy EJB (come ottimizzarlo in modo da effettuare il minor numero di
restar dell’AS)
Ci terrei ad avere le vostre opinioni,
Grazie, ciao
Max.
--------------------------------
Inviato via 
http://usenet.libero.it

 di portata Enterpise ?
Fare una bella analisi, dividere il lavoro in parti piu' o meno uguali
e relativamente isolate, usare estensivamente un sistema di controllo
versioni (CVS) per il codice comune e testare spesso.
Davide

 ha scritto nel messaggio
news:aprhq8$47rn5$6...@ID-18487.news.dfncis.de...

Per il sistema di controllo versioni usa Microsoft SourceSafe x windows o
SourceOffSite

Davide, grazie mille per la risposta
Nel momento in cui si procede al Testing del codice, quale modalità si
utilizza?
Intendo dire, ogni client deve avere sulla sua macchina installato una copia
dell'AS e del progetto e li provvede a testare il codice, oppure, preleva il
codice direttamente dal server, lo modifica, e poi provvede a testarlo
direttamente sul server?
Grazie.

--------------------------------
Inviato via 
http://usenet.libero.it

 SourceOffSite
CVS e' meglio e piu' sicuro. Ho avuto molti database andati a ramengo
con MS SourceSafe, tante' vero che in ditta stiamo sostituendo tutto
con CVS. Inoltre CVS e' gratuito e consente aggiornamenti remoti
tramite ssh.
Davide

 utilizza?
Se il progetto e' sufficientemente grosso ogni sviluppatore dovrebbe
avere un AS installato sulla sua macchina o dovrebbe esserci un'AS
disponibile per i test "normali", piu' un server di prova da usarsi
una o piu' volte alla settimana per compilare tutto l'applicativo
(prelevando i sorgenti direttamente dal CVS) e verificare le funzionalita'
intere.
Ogni volta si testa tutto + le nuove funzionalita' aggiunte.
Davide

 Ci terrei ad avere le vostre opinioni,
"Migliore", non saprei. :) Quello che faccio usare al mio gruppo al 
momento:
 - Eclipse (consigliato): se uno vuole, puo' usare UltraEdit :-)
 - Perforce come version control system; per me e' il migliore, ma
   l'essenziale e' che permetta di gestire grandi volumi di codice (la
   nostra codebase comprende circa 3500 changes per un totale di svariati
   gigabyte di history) _e_ abbia la possibilita' di accesso al di fuori
   della lan, per lavori on-site. Insomma, lascia perdere visual 
   sourcesafe ;-)
 - DevTrack come bug tracking system (ma solo perche' e' facile da usare)
 - build system basato su ant, che usa:
    	- codelines. Una codeline consiste in un set di moduli ed ha una
       root convenzionale su file system; inoltre, puo' essere di 
       development oppure release (frozen).
       In particolare una codeline definisce il "core" del sistema; e per
       ogni applicazione/cliente c'e' una codeline.
     - le codeline applicative sono marcate come "environment-dependent" o
    	  no (nel primo caso si possono testare solo sul campo; nel secondo si
       possono testare in house).
    	- un modulo definisce un componente, definendo (via un file di     
	  proprieta'):
    	    	- nome
    	    	- source code
     	- tipo (jar, jar exeguibile, ejb-jar, war, rar, eccetera)
    	    	- altre informazioni
    	  Inoltre, in codelines diverse dal core, si possono definire
    	  moduli dallo stesso nome di un modulo core, la cui semantica e' 
       di "incrementare" o fare l'override del contenuto del 
    	  corrispondente modulo core; ad esempio, per una servlet, il 
    	  descriptor del core non contiene informazioni di security, 
    	  permettendo ai programmatori di fare test senza preoccuparsi 
    	  della security; il corrispondente modulo in una codeline applicativa
    	  contiene invece il setup di security per quell'applicazione, ed e'
    	  quello usato dal tester di production (che magari
    	  Ogni modulo e' inoltre associato ad una test suite.
    	- per ogni modulo, c'e' un head version, che e' un branching "frozen"
    	  del modulo; per ogni codeline, c'e' una release version (ancora, un
       branching di quanto necessario) che specifica il set di head version
       di moduli a cui la codeline fa riferimento, piu' qualunque altra
    	  cosa che debba essere "frozen".
   	- un sistema di discovery (scritto in Java) che conosce le convenzioni
    	  ed e' in grado di esplorare il file-system per trovare cose e 
       perrmettere la costruzione di tool utili :) e di
    	  aggiungere/modificare moduli semplicemente operando sul file system
    	- nel caso di applicazioni J2EE, ogni codeline ha una copia
    	  dell'application server sotto la root della codeline stessa.
    	  Per risparmiare spazio nel VCS, in quello ci vanno solo i files
    	  di configurazione: la prima volta che si installa una codeline
    	  su una macchina, bisogna installare l'application server prima.
    	- una copia del tutto (se serve) su ogni workstation;
    	- un set di macchine di test, contententi database condivisi, etc.
    	- altre frattaglie varie :)
Il tutto funziona benone; l'unico problema che al momento non trattiamo e' 
il fatto che la configurazione dell'appserver puo' richiedere hardcoding di 
certe cose (o meglio, non permettere di paremetrizzarle efficientemente): 
ad esempio, l'URL di una datasource o cosi' via. Quindi talvolta e' 
necessario tenere checked-out parte della configurazione su una certa 
macchina perche' sarebbe impratico tentare di parametrizzare detta 
configurazione.
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

Non č che il progetto si chiama "SIO" ?
Cmq, la cosa migliore č partire da una analisi dati chiara ed esaustiva,
come infondo dovrebbe essere in ogni progetto. Evitate di iniziare a
scrivere codice senza aver finito al fase di progettazione, il rischio č un
doloroso disallineamento del codice.
Evitate, solo per rendere il programma piů elegante, pattern inutili e
modularizzazioni eccessive che non fanno altro che rendere piů complesso il
processo di debug e di manutenzione (a meno che non sia indispensabile). In
altre parole non fate un applicativo a 4 strati quando ne bastano 3 (sembra
una ovvieta ma talvolta ci si fa prendere da strade affascinanti che alla
fine si rivelano faticose da percorrere, soprattuto quando si hanno delle
scadenze e dei clienti assetati di sangue :-)
Per quanto riguarda il punto 3 credo che l'unica cosa sia adottare
metodologie di deploy automatico e munirsi di tanta pazienza.
Auguri.