Database version control

giovedì 3 aprile 2008 alle 03:08 | Pubblicato su Diario | 2 commenti

nota: questo post è fra le mie bozze da un paio di mesi, oggi, stanco di vederlo li lo pubblico ufficialmente.

Vorrei ringraziare Tom Kyte per il post “Hear hear “, o meglio per il link che porta al blog di K. Scott Allen ,in particolara ad una serie di post intitolata “Versioning Databases”, in cui questo blogger da delle linee guida (o best practices) che sarebbe utile seguire per la gestione della base dati quando si sviluppa un prodotto.

La serie è composta da 5 post:

1) Three rules for database work

2) The baseline

3) Change Scripts

4) Views, Stored Procedures and the likes

5) Branching and merging

Sono d’accordo con quasi tutto quando viene detto. Solo una parte mi lascia perplesso, la prima delle regole descritta nel primo post: “mai usare un database condiviso per i lavoro di sviluppo”.

Nell’azienda dove lavoro grosso modo il ciclo di sviluppo e rilascio segue le regole descritte da Scott Allen, ad esclusione senz’altro di quella prima regola. Attualmente la ritengo inapplicabile al mio caso. I programmatori vogliono avere una base dati con dei dati con cui lavorare e moltiplicarle per 40/50 non è una cosa facile da gestire. Non è neppure facile addestrare ed imbrigliare i programmatori a seguire tali procedure, il rapporto vantaggi/svantaggi nella mia esperienza sarebbe senz’altro negativo.

In realtà noi abbiamo un approccio semplificato e un po’ più disordinato. I programmatori depositano in un certo posto gli script relativi alle modifiche della base dati collegati ai loro sviluppi software, si fanno le modifiche in autonomia al database di sviluppo che è condiviso. Quando qualcuno lo stabilisce si fa un rilascio in test che consiste nel raggruppare tutti gli script depositati dai programmatori, metterli in un unico script collegato alla versione del software e tale script viene inserito nel package software. Il package software contiene anche una procedura, lanciabile sia da linea di comando che dal programma stesso, quindi tramite interfaccia grafica, che si occupa di confrontare la versione della base dati con la versione del package software e di allinearla se necessario. Quindi quando si installa nell’ambiente di test la prima cosa a venir testata è la correttezza degli script di aggiornamento della base dati.

Io, insieme a dei colleghi mi occupo di queste procedure di rilascio che inevitabilmente comportano un lavoro manuale piuttosto noioso di controllo e test degli script preparati dagli sviluppatori, i quali non sono molto disciplinati.

Questo approccio alleggerisce i programmatori dalla responsabilità di preparare script assolutamente esenti da errori, trasferendo il compito di verificare, correggere e impacchettare tali script ai rilasciatori. Devo dire che dal punto di vista mio (cioè dei rilasciatori) la cosa non è fantastica, ma è un ottimo compromesso. Si richiede cioè alle poche persone che si occupano dei rilasci una maggior attenzione, lasciando ai programmatori (che sono un po’ così come dire, artisti) più libertà.

D’altra parte ai programmatori è lasciata la gestione della base dati di sviluppo, quindi se fanno casini li si arrangiano fra loro.

2 commenti »

RSS feed for comments on this post. TrackBack URI

  1. In effetti sono trasalito pure io quando ho letto la prima regola e l’ho calata all’interno del mio team di sviluppo.

    Comunque: come dicevo qui http://sonoundottore.blogspot.com/2008/02/cosa-diavolo-aspettano.html sarebbe una bella cosa avere un tool standard, magari integrato in oracle, per effettuare il versioning dello schema sui sistemi tradizionali di version (CVS, SVN, VSS ecc…).
    Penso ad un package che faccia, lato server, il salvataggio sul repository di tutto gli script di definizione e li possa scaricare ed eseguire in un qualunque altro schema/database, in modo da facilitare il trasporto dev/QA/prod….

  2. Diego,
    sono perfettamente d’accordo con quanto dici. Personalmente infatti mi trovo costretto a editare i file salvandoli in locale e utilizzando il CVS come sistema di versionamento. Ho però notato che molte persone si adeguano al metodo supportato da tutti gli strumenti che ho visto: editare direttamente il codice sul database. Io questo lo trovo sbagliato. Quindi ripeto sono perfettamente d’accordo con quando dici nel tuo post. In effetti ieri quando l’ho visto volevo proprio manifestarti la mia solidarietà🙂


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: