Come sapete, 4D ora supporta due modi di lavorare con i sorgenti: database binari e database di progetto. I database binari sono il 4D che tutti conosciamo e amiamo, con il codice sorgente in un file binario per consentire lo sviluppo in team con 4D Server e tutti gli elementi di progettazione (metodi, moduli, struttura, ecc.) raccolti in un unico file binario compatto, il file “.4db”. I database di progetto facilitano il lavoro collaborativo dei team distribuiti, memorizzando il codice sorgente in un sistema di controllo sorgente in file di testo semplici e separati. I progetti non sostituiranno il 4DB e non abbiamo intenzione di far scomparire il 4DB. Si tratta di due modi diversi di lavorare e sviluppare. Sta a voi scegliere quello che meglio si adatta alle vostre esigenze. Ecco un post del blog che vi aiuterà a decidere:
Database binario (.4DB)
Pro
- Sviluppo multiutente
Più utenti possono sviluppare e progettare un database contemporaneamente. L’integrità del progetto del database è preservata da un sistema di blocco degli oggetti integrato.
- Lavorare sulla stessa versione
Il database è ospitato sul server 4D. Tutti gli sviluppatori lavorano sulla stessa versione del codice.
- Visualizzazione diretta del lavoro degli altri sviluppatori
Potete vedere l’ultimo sviluppo di un altro sviluppatore senza modificarlo(ad esempio, per controllare i punti di ingresso e di uscita di un metodo che dovrete chiamare nella vostra parte di codice).
- Sistema di backup integrato
4D Server include un modulo completo di backup e ripristino del database. Questo modulo consente di eseguire il backup di un database durante il funzionamento, senza doverlo abbandonare. I backup possono essere lanciati manualmente o automaticamente, a intervalli regolari e senza l’intervento dell’utente.
Cons
- In linea
Richiede un accesso permanente al server.
- Rollback complicato
Etichettare una versione del cliente e poter tornare a questa versione in caso di feedback del cliente può essere una sfida.
- Compilazione
È possibile compilare solo un client 4D alla volta.
- Complicato testare in modalità compilata
È necessario riavviare il server per i test, quindi tutti gli altri sviluppatori ne risentono.
- Difficile gestire più versioni
Non è possibile unire automaticamente le patch da una versione all’altra. Richiede un rapporto manuale: trovare le linee modificate e poi integrarle nell’altra versione.
Database del progetto (.4Dproject)
Pro
- Offline
Possibilità di sviluppare ovunque(ad esempio, in ufficio, in viaggio, ecc.).
- Storia
La memorizzazione in un sistema di controllo dei sorgenti semplifica notevolmente la possibilità di seguire l’evoluzione delle modifiche: la data, l’autore e le righe modificate.
- Rollback di uno sviluppo
Se una nuova integrazione destabilizza la vostra versione, è facile tornare a una versione precedente.
- Sviluppo multiversione
È facile unire le patch da una versione all’altra grazie al sistema di ramificazione di un sistema di controllo dei sorgenti.
- Compilazione in qualsiasi momento
Possibilità di compilare e testare in modalità compilata senza limitazioni.
- Set di funzionalità migliorate
Semplificazione della distribuzione per utenti e gruppi, miglioramento dei fogli di stile grazie ai CSS e così via (leggete i post dedicati ai database di progetto per scoprire tutte le nuove possibilità).
Cons
- Sviluppo con codice sorgente distribuito
Ogni sviluppatore codifica da solo sulla propria copia del codice. Necessità di organizzazione e regole per facilitare la condivisione del lavoro.
- L’accesso al codice da un client è di sola lettura.
È possibile eseguire test e debug in Client/Server, ma non è possibile modificare il codice distribuito sul server. È necessario riaprire il database con 4D Developer, effettuare la modifica e riavviare il server.
Per concludere
I database di progetto aprono nuove prospettive e offrono un altro modo di lavorare con 4D. Ma tenete presente che non esiste un modo migliore. Siete liberi di scegliere quello che meglio si adatta alle vostre esigenze.