Il documento discute l'uso dei Database Projects in Visual Studio per facilitare lo sviluppo e la gestione dei database in un contesto di Application Lifecycle Management (ALM). Viene approfondita l'importanza del controllo di versione, della generazione di script per il deploy e del testing unitario, evidenziando come questi strumenti possano migliorare l'efficienza e ridurre gli errori. Inoltre, il documento menziona l'estendibilità e le funzionalità specifiche dei Database Projects, come il supporto per diversi sistemi di database e l'integrazione con strumenti di build.

1. Visual Studio Database projects

2. AutoreRicci Gian MariaE-mail: ricci.gm@nablasoft.comBlog: http://www.nablasoft.com/alkampferhttp://blogs.ugidotnet.org/rgm

3. Alm e database, le problematiche attualiParte prima

4. Database ed ALM - Problemi

5. Soluzioni tradizionaliDatabase di sviluppo condivisoAggiornamento tramite script sequenzialiEstrema difficoltà nel monitorare la vita degli oggetti

6. Assenza di script per il rollback delle modifiche

7. Difficoltà nell’individuare lo sviluppatore che ha scritto una specifica porzione di codiceSoluzioni tradizionali – Source ControlIl database è modellato da script sequenzialiALTER TABLE CUSTOMER…ALTER VIEW ORDERBYCUST…CREATE TABLE SHIPPING…ALTER VIEW ORDERBYCUST…ALTER TABLE CUSTOMER…ALTER TABLE SHIPPING…

8. Soluzioni tradizionali - DeployConfronto con una struttura master per la generazione di script di updateDEVProdConfronto con una struttura master per la generazione di script di update

9. Si deve generare uno script per ogni possibile versione che si ha in produzione

10. Problemi nel caso il database di produzione sia stato modificato Soluzioni tradizionali - TestingDifficile gestire il database di test localeGenerazione di script di creazione DB e procedure manuali che ricreano il DB per i testGenerazione di dati manuali.DatiTest Data DBTestStrutturaDEV SCHEMASandbox

11. Database Project Visual Studio Database Edition (Team System Developer o Team Suite) introduce il concetto di Database ProjectUn Database Project è un progetto dedicato per lo sviluppo di databaseLo scopo finale è garantire un’integrazione completa dello sviluppo DB nell’ALM

12. Quando introdurre un Database Project nel ciclo produttivo Grazie all’importazione automatica è possibile introdurre un Database Project anche in un progetto iniziatoLe molte funzionalità fornite, tra cui il controllo sintattico e dei riferimenti tra oggetti porta immediati vantaggi.E’ comunque necessario che gli sviluppatori abbiano una familiarità con lo strumento, per cui è consigliabile un progetto pilota Operare immediatamente su un progetto relativo ad un database complesso può essere dispersivoImportazioneDB DevDB Project

13. Demo – familiarizzare con i database project

14. Ogni oggetto un fileIl paradigma più importante è che ogni oggetto è identificato da un file sorgenteIn questo modo è possibile confrontare le varie versioni e monitorare l’evoluzione degli oggetti del database nel tempoIl database viene effettivamente “modellato” partendo da dei file sorgenteCREATE TABLE [dbo].[Customers] ( [CustomerID] NCHAR (5) NOT NULL, [CompanyName] NVARCHAR (40) NOT NULL, [ContactName] NVARCHAR (30) NULL, [ContactTitle] NVARCHAR (30) NULL, [Address] NVARCHAR (60) NULL, [City] NVARCHAR (15) NULL,…CREATE TABLE [dbo].[Customers] ( [CustomerID] NCHAR (5) NOT NULL, [CompanyName] NVARCHAR (40) NOT NULL, [ContactName] NVARCHAR (30) NULL, [ContactTitle] NVARCHAR (30) NULL, [MainAddress] NVARCHAR (60) NULL, [City] NVARCHAR (15) NULL,…

15. Sviluppo dichiarativoUn database project contiene al suo interno tutte le dichiarazione di creazione degli oggettiSi può passare dalla dichiarazione, alla generazione del database e di nuovo al codiceNel database project sono contenute le definizioni di tutti gli oggetti che compongono un database: tabelle, storedprocedures, funzioni, utenti, assembly CLR, trigger, indici, etc.Tutti questi file sorgente possono essere “compilati” per generare artefatti.Per contro gli sviluppatori necessitano della conoscenza della sintassi T-SQL relativa alla creazione degli oggetti, ma si può sempre usare il Management Studio e poi portare il codice in Visual Studio

16. Database Logico Un Database Project definisce quindi un “database logico”che è il risultato della compilazione di un database projectLa compilazione individua eventuali errori di sintassi nelle definizioni degli oggetti

17. Vengono individuate anche anomalie, come riferimenti ad oggetti inesistentiCompilazioneAnalizzando i sorgenti viene creato lo schema modelProgetto databaseSchema Model.dbschemaIl modello viene Interpretato, analizzato e validatoEventuali anomalie nel codice vengono comunicate con errori e warning, esattamente come avviene durante la compilazione di un normale progetto C# o VB

18. Compilazione

19. Analisi di codice Procedura analoga a quella disponibile sui normali progetti C# o VBPermette di analizzare il Database Project al fine di evidenziare pattern di codice criticiSuddivise in tre distinte categorie: Naming, Performance e Design attivabili distintamentePossibilità di attivare/disattivare non solo le categorie ma i singoli warningMostra punti con possibili problemi nel codice.

20. Controllo di versioneVisualizzando la storia di un file si ottiene la storia del corrispondente oggetto del DBSi può effettuare un confronto tra le versioni per vedere come un oggetto è cambiato nel tempoSi può capire chi e quando ha scritto una particolare porzione di codice e perchéSi può effettuare un rollback annullando le modifiche

21. DEMO – compilazione e Controllo di codice sorgente

22. DeployIl database logico può essere confrontato con un database fisico per generare uno script di aggiornamentoIl confronto non necessita di avere una istanza “viva” del database di sviluppoConfrontoDB LogicoDB Fisico

23. Deploy in produzioneLe modifiche possono anche essere applicate immediatamente senza passare per uno script DB FisicoDB LogicoVengono generati alert in caso l’aggiornamento causasse una perdita di dati

24. Il confronto e l’aggiornamento vengono fatti tramite un tool ridistribuibile e gratuito, oppure direttamente da Visual StudioSincronia inversaSi può procedere anche in direzione inversa, ovvero sincronizzare da un database fisico ad un database logico (solo da Visual Studio)DB FisicoDB LogicoQuesta procedura è utile, quando alcune persone non posseggono una versione che supporti i Database Project, ma debbono comunque poter modificare lo schema di database

25. Un’altra situazione è quella in cui un database di test viene ottimizzato da un DBA, che crea indici o modifica le viste direttamente in un’istanza di test.

26. In questo modo è sufficiente effettuare una sincronia al contrario per portare le modifiche, da un database reale, al Database ProjectGestire versioni multiple1.21.5Il database logico permette di sincronizzare versioni multipleNon è necessario sapere a priori la versione per fare un aggiornamento2.3

27. Come viene effettuato il deployIl confronto passa sempre per lo schema modelLe differenze vengono calcolate in base agli Schema ModelSulla base delle differenze viene generato lo script di upgradeNella generazione si tiene conto delle caratteristiche delle varie versioniSchema ModelSchema ModelDiff

28. Interfaccia per VsDbCmd.exeIl tool di deploy è un utility a riga di comando chiamato VSDBCMD.exeIl formato “Riga di comando” è eccezionale per includerlo in procedure automatiche di setup e di aggiornamento del db.L’essere ridistribuibile permette di includerlo in programmi di aggiornamento senza spese di sortaPer semplificarne l’uso, un MVP Team System ha sviluppato una interfaccia grafica che permette di specificare le opzioni tramite una GUI molto più userfriendly rispetto alla modalità in riga di comando.Ulteriori dettagli sul mio blog http://blogs.ugidotnet.org/rgm/archive/2009/10/14/una-mini-ui-per-vsdbcmd.exe.aspx

29. DEMO Deploy

30. Unit test del databaseSi possono creare con pochi click unit test di stored procedure, trigger e funzioniVisual Studio si occupa di generare il database di test, allinearlo ed eseguire la generazione dati

31. Il test è scritto in T-SQL

32. I test sono ripetibili e robusti.Unit Test del databaseSandbox: Ogni sviluppatore effettua i test nella sua macchina localeI test non causano iterazione, ogni sviluppatore può testare in completa autonomiaLa validità del Sandbox, sia come struttura e come dati viene garantita dal Visual StudioSi evitano quindi i classici problemi legati al test del databaseGenerazione datiData Generation PlanTestAllineamento strutturaDatabase ProjectSandbox

33. Unit test del databaseEquiparazione tra database unittesting e code unittestingStrutturazione del test con il classico fourphase test.Dietro le quinte è sempre presente un normale test C# o VisualBasic generato dal designer, che costituisce il wrapper del database test.La classe wrapper può, se necessario, essere modificata per aggiungere funzionalitàWrapperFixtureSetupT-Sql CodeTestSetupT-Sql CodeTestT-Sql CodeTestCleanupT-Sql CodeFixtureTeardownT-Sql Code

34. Unit Test del database - Asserzioni

35. Data Generation PlanMotore di generazione di dati per test.Altamente configurabileRispetta chiavi, relazioni e vincoli del databaseGenera dati in maniera ripetibilePuò generare dati sulla base di dati preesistenti su un database di testEspandibile con generatori custom per soddisfare qualsiasi esigenza

36. DEMO Unittesting

37. RefactoringAlcune operazioni su db sono molto invasive, come ad esempio il rinominare una colonna di una tabellaGrazie alla conoscenza della struttura, in un Database Project questa operazione può essere automatizzataIl Visual Studio mostra tutte le modifiche che verranno effettuate al progetto prima di aggiornare tutti gli oggetti che fanno riferimento all’oggetto modificatoÈ possibile avere una preview dettagliata per capire l’impatto che la modifica avrà nel databaseI refactoring sono possibili sia per le tabelle, ma anche per altri oggetti, come trigger, storedprocedures, funzioni

38. Refactoring - DettagliTabelleRename: Rinomina una tabella o colonnaMoveToSchema: Sposta una tabella in uno schema differenteFullyQualifyName: Qualifica in modo completo i nomi con il nome a tre parti databasename.schema.nameView (tutte quelle delle tabelle più)ExpandWildcards: Analizza una stored ed ogni volta che viene trovato il wildcard * in una selezione lo espande.Stored e funzioniRename: Rinomina una stored funzione o parametroMoveToSchema: Sposta una tabella in uno schema differenteExpandWildcards: Analizza una stored ed ogni volta che viene trovato il wildcard * in una selezione lo espande.FullyQualifyName: Qualifica in modo completo i nomi con il nome a tre parti databasename.schema.name

39. Altre caratteristiche Visualizzazione dipendenzePermette di visualizzare, partendo da un oggetto radice, le dipendenze che esso ha nel database.Vengono mostrati gli oggetti che dipendono dall’oggetto radice, ma anche gli oggetti da cui l’oggetto radice dipendeÈ possibile gestire le ExtendedProperty dei vari oggettiSupporto dell’integrazione con CLRPossibilità di aggiungere assembly al database projectGestione dei tipi nativiModella qualsiasi oggetto supportato dal motore di databaseCertificatiChiavi di sicurezzaUtentiCode / ServiziEtc.

40. Tip and tricks

41. Mantenere il numero di versioneÈ sempre utile creare e mantenere una tabella con il numero di versione nel databaseNel post deploy script si aggiunge uno script per inserire il numero di versione, solitamente si esegue un insert, in modo da conoscere tutte le versioni passate di un databaseFondamentale quando avvengono modifiche al db che non possono essere propagate automaticamente dal tool di aggiornamento struttura. In questo caso infatti un predeployment script, può effettuare aggiornamenti specifici, conoscendo il numero attuale di versione.Utile se da codice si vuole permettere di usare una versione vecchia del database senza forzare un aggiornamento.Fondamentale per diagnostica, permette di capire la storia del database in caso di problemi

42. Ridurre le dimensioni degli script di referenceI file di riferimento delle strutture master sono molto grandi e rallentano molto il Visual StudioDato che sono file normali XML se ne può fare una copia e lasciare in essa solo le funzioni che si vogliono referenziare.Questa operazione può cambiare drasticamente i tempi di apertura del progetto e di compilazione.Necessario ogni qualvolta si faccia riferimento a funzioni base presenti nel database Master

43. Eseguire programmaticamente un data generation planAi fini del testing può essere molto utile eseguire in maniera programmatica un Data Generation PlanÈ possibile sfruttare msbuild da codice C# o VB per automatizzare l’operazione.In questo modo si può decidere quando e quale piano di generazione eseguire prima di ogni test.Generation PlanTest Data DBDatabase Project

44. Integrazione con Team BuildE’ possibile integrare il deploy del progetto DB in una team build. Es, progetto web.In questo modo si automatizzano le procedure di deploy, sia nell’ambiente di test che in produzioneTFSAggiorna Web Check InSincronizza DBBuild ServerDB Test

45. Test In memoria Grazie al concetto di “variabili” è possibile parametrizzare i sorgenti del progettoIn particolare si può utilizzare un RAMDisk e far creare i file di database in memoriaUtilizzando questa tecnica per un deploy locale per gli unittesting, si può velocizzare l’esecuzione.Test in memoria

46. Test transazionaliUn test transazionale è un test che non modifica il contenuto del dbÈ possibile rendere ogni test di database transazionale semplicemente aggiungendo codice alla classe wrapper.In questo modo dopo ogni test il contenuto del database viene riportato al contenuto iniziale, ed i test sono più ripetibiliWrapperFixtureSetupTest SetupBeginTransactionTestExecute test codeTestCleanupRollbackTransactionFixtureTeardown

47. DEMO Unittesting