|
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 sviluppoa 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 grossomodo 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 sviluppoatori, 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. |
