Eqepa dbms-svn-web

Eqepa Dbms Svn System SVN-Server DBMS-server SVN-Client DBMS-server SVN-Client DBMS-server SVN-Client DBMS-server

Sommario
Introduzione al problema
Svn per sviluppo web
Esigenze
Idea
LiquiBase e svn Hook
Architettura della soluzione
Conclusioni e sviluppi futuri

Introduzione al problema-1
L'utilizzo del versionamento del codice sorgente è una necessità per tutti gli sviluppatori
Con gli strumenti attuali è facile condividere lo sviluppo di applicazioni composte da un insieme di file testuali
Al contempo però con un architettura classica non è possibile condividere (sviluppare) applicazioni che fanno riferimento a server dbms per la gestione dei dati che esse utilizzano

Introduzione al problema-2
In generale applicazione e dbms vengono considerate entità separate
Questo è causa sia di una divisione nel team di sviluppo, e sia di enormi problemi di gestione dei dati
L'obiettivo è quello di trovare un'architettura di versionamento che permetta di condividere codice e dati di un applicazione in maniera facile e automatizzata
Questo problema è all'ordine del giorno per tutti i team di sviluppo di web-applications

Svn per sviluppo web
Ogni applicazione web è composta da un insieme di file testuali di diversa natura, ma sopratutto da un una raccolta di dati contenuti in un dbms necessari per il suo funzionamento
L'utilizzo di CMS ha accresciuto l'utilizzo dei database per il mantenimento di informazioni riguardanti anche la parte di interfaccia di queste applicazioni
In definitiva è molto difficile accedere ad una risorsa identificata da un url senza fare accesso ai dati contenuti in un server dbms

Esigenza
Quello che ogni sviluppatore web vorrebbe è che al momento del commit, a fronte di modifiche sul codice sorgente, corrisponda un commit delle modifiche effettuate sul suo database locale verso quello sul server svn
A questo punto ogni altro membro del team di sviluppo, effettuando un update del codice effettuerà anche una sincronizzazione della struttura e del contenuto del database usato dall'applicazione
Il codice e il database sarebbero cosi, sempre sincronizzati

L'Idea
I dati contenuti in un dbms possono essere rappresentati da una sequenza di operazioni testuali (log) che eseguite una dopo l'altra riportano lo stato della base dati coerente con quello specificato nel file
L'idea è quella di rappresentare in formato testuale le differenze tra una base dati di riferimento (su un server-svn)
e quella locale di ogni sviluppatore
Eseguendo le operazioni specificate il dbms di riferimento si porterà in un stato coerente con quello dello sviluppatore che ha eseguito le modifiche

LiquiBase e svn Hook-1
Per questo scopo ci vengono in aiuto due tecnologie non molto conosciute ma di particolare utilità:
Liquibase e svn Hook
Il primo è un tool, java, in grado di generare un file xml contenente le operazioni da eseguire per ricreare lo stato del db su cui esso è applicato
Il secondo è il sistema di gestione degli eventi presente nativamente in svn che permette di associare script batch o file eseguibili in reazione agli eventi di commit e update.

Grazie al comando diffChangeLog di liquibase è possibile generare un file xml contenente tutte le differenze (a livello di schema) tra un db base (sviluppatore) ed uno globale di riferimento (server-svn)
Al momento del commit, prima che questo avvenga, si scatenarà l'evento pre-commit che invocherà la procedura di creazione del file di changeLog
Essendo questo file versionato, il suo contenuto sarà inviato al server-svn, sfruttando l'evento post-commit le operazioni in esso specificate saranno ripetute nel dbms di riferimento

Al momento di un operazione di update da parte di qualsiasi client, il file change log sarà portato nell'ultima revisione
contenente le modifiche effettuate sul dbms di riferimento
A questo punto basta invocare, a fronte dell'evento post-update sul client, la procedure di liquibase che pemette di applicare le operazioni indicate nel file di log
A successive modifiche del db corrisponderà un aggiunta delle operazioni da sincronizzare in coda a questo file che quindi conterrà lo stato corrente del db per ogni revisione.

Architettura della soluzione SVN-Server DBMS-server SVN-Client DBMS-server SVN-Client DBMS-server SVN-Client DBMS-server

Architettura della soluzione SVN-Server DBMS-server SVN-Client DBMS-server SVN-Client DBMS-server SVN-Client DBMS-server Il client esegue modifiche al codice e sulla struttura del db. Successivamente esegue un commit verso L'svn server. Sul client si scatenerà l'evento pre commit che causerà la generazione del file di log che conterrà le differenze tra la base dati di riferimento e quella locale. Successivamente il codice viene Condiviso.

Architettura della soluzione SVN-Server DBMS-server SVN-Client DBMS-server SVN-Client DBMS-server SVN-Client DBMS-server Il server svn riceverà il codice Dal client ed eseguirà le Operazioni necessarie per il Corretto versionamento. A questo Punto si scatenerà l'evento post Commit che causerà sul server L'invocazione della procedura Di liquibase per l'esecuzione delle Operazioni contenute nel file di Log

Architettura della soluzione SVN-Server DBMS-server SVN-Client DBMS-server SVN-Client DBMS-server SVN-Client DBMS-server Al momento dell'update da parte Di qualsiasi client questo riceverà Il file changelog relativo all'ultima Revisione, quindi, contenente le Ultime modifiche effettuate sul Dbms di riferimento. A questo Punto gestendo l'hook Post-update su ogni client si Invocherà l'esecuzione della Procedura liquibase per L'aggiornamento del dbms lato client

Eqepa dbms-svn-web

by bistrulli on Jun 27, 2010

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 80

Statistics

Eqepa dbms-svn-web — Presentation Transcript