Panoramica

Questa presentazione è nata in risposta a problematiche reali e attuali nell’abito dello sviluppo collaborativo di applicativi web.
L’obiettivo è quello di presentare un architettura di massima, insieme a metodologie e tecnologie, per realizzare un sistema di versionamento e condivisione del contenuto di una base di dati.

Introduzione al Problema

L’utilizzo del versionamento del codice sorgente è una necessità per tutti gli sviluppatori, la messa in opera di una buona piattaforma di versionamento è il primo passo per lo sviluppo di qualsiasi applicazione. L’utilizzo di questi tool non è solo legato allo sviluppo in team, ma grazie alle funzionalità di rollback, rappresenta uno strumento indispensabile per rendere affidabile l’intero processo di vita del software anche se lo sviluppo è individuale.
Con gli strumenti attuali è facile condividere lo sviluppo di applicazioni composte da un insieme di file testuali.
Al contempo però con un architettura di versionamento classica non è possibile condividere (sviluppare) applicazioni che fanno riferimento a server dbms per la gestione dei dati che esse utilizzano.
In generale applicazione e dbms vengono considerate entità separate, la prima è individuata come l’insieme dei file sorgenti che gestiscono la logica applicativa mentre, la seconda, come l’insieme di dati gestiti da un server dbms. L’evoluzione di queste due entità non viene mai, o quai mai, vista come un processo sincrono e paralello ma, in genearle, è portata avanti come processi indipendenti.
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

Svn per sviluppo web

Questo problema è all’ordine del giorno per tutti i team di sviluppo di web-applications. Ogni applicazione, in questo mondo, è composta da un insieme di file testuali di diversa natura, ma sopratutto da una raccolta di dati contenuti in un dbms necessari per il suo funzionamento.
L’avvento dei CMS ha accresciuto l’utilizzo dei database per il mantenimento di informazioni riguardanti anche la parte di interfaccia di queste applicazioni in definitiva, quindi, è 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.
Per questo scopo ci vengono in aiuto due tecnologie non molto conosciute ma di particolare utilità:
Liquibase e svn Hooks
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 scatenerà 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.