SQL Server Development Tools & Processes Using Visual Studio 2010
2 likes1,078 views
The document discusses database development using database projects in Visual Studio. It covers topics like: 1. Using database projects to model schemas offline and perform schema refactoring and incremental deployments. 2. Reverse engineering existing databases into schema models and using model diff to determine changes for deployment. 3. Integrating database projects with source control and work item tracking in Team Foundation Server (TFS) for development workflows. 4. Automating builds, deployments, testing and change management using TFS for database projects.
SQL Server Development Tools & Processes Using Visual Studio 2010
- 1. Microsoft Most Valuable Professional (MVP) www.aymanelhattab.com Twitter: @AymanElHattab
- 16. class AuctionApplication class AuctionApplication class AuctionApplication ( ( ( App int id; int id; int id; void MethodA(); void MethodA(); string cacheTitle; ) void MethodB(); void MethodA(); ) void MethodB(); ) V1 V2 V3 Revision History CREATE ALTER TABLE dbo.Auction TABLE ALTER TABLE dbo.Auction dbo.Auction Database ( WITH CHECK ADD CONSTRAINT WITH CHECK ADD CONSTRAINT id INT NOT PRIMARY KEY (id) Au_PK Au_SK UNIQUE (name) NULL, name VARCHAR(25) NOT NULL, start DATETIME NULL, len INT NULL )
- 17. -- version 1 Add table dbo.Auction IF OBJECT_ID (N'dbo.Auction', N'U') IS NULL BEGIN CREATE TABLE dbo.Auction ( id INT NOT NULL, name VARCHAR(25) NOT NULL, start DATETIME NULL, len INT NULL ) END -- version 2 Add PK Au_PK IF NOT EXISTS (SELECT * FROM sys.key_constraints WHERE name = 'Au_PK' AND type = 'PK') BEGIN ALTER TABLE Auction WITH CHECK ADD CONSTRAINT Au_PK PRIMARY KEY (id) END -- version 3 Add UC Au_SK IF NOT EXISTS (SELECT * FROM sys.key_constraints WHERE name = 'Au_SK' AND type = ‘UQ') BEGIN ALTER TABLE Auction WITH CHECK ADD CONSTRAINT Au_SK UNIQUE (name) END
- 18. class AuctionApplication class AuctionApplication class AuctionApplication ( ( ( App int id; int id; int id; void MethodA(); void MethodA(); string cacheTitle; ) void MethodB(); void MethodA(); ) void MethodB(); ) Source-controlled and deployed scripts V1 V2 V3 do not need to match! Revision History CREATE CREATE CREATE dbo.Auction TABLE dbo.Auction dbo.Auction TABLE TABLE Logical In- ( ( ( Memory id INT NOTid NOT NULL PRIMARY KEY, KEY, id INT NULL,INT NOT NULL PRIMARY Database name VARCHAR(25) NOT NULL, NULL, NULL UNIQUE, name VARCHAR(25) NOT name VARCHAR(25) NOT start DATETIME NULL, NULL, NULL, start DATETIME start DATETIME len INT NULL NULL NULL len INT len INT ) ) )
- 19. CREATE CREATE CREATE dbo.Auction TABLE dbo.Auction dbo.Auction TABLE TABLE Logical In- ( ( ( Memory id INT NOTid NOT NULL PRIMARY KEY, KEY, id INT NULL,INT NOT NULL PRIMARY Database name VARCHAR(25) NOT NULL, NULL, NULL UNIQUE, name VARCHAR(25) NOT name VARCHAR(25) NOT start DATETIME NULL, NULL, NULL, start DATETIME start DATETIME len INT NULL NULL NULL len INT len INT ) ) ) V1 V2 V3 Revision History New Incremental Deployment CREATE TABLE dbo.Auction Deployment ALTER TABLE dbo.Auction ( WITH CHECK ADD CONSTRAINT id INT NOT NULL PRIMARY KEY, Au_SK UNIQUE (name) name VARCHAR(25) NOT NULL UNIQUE, start DATETIME NULL, V2 len INT NULL )
- 20. Source Interpret, Database analyze and validate Reverse engineer Schema Model schema into DDL artifacts Database Project Build .dbschema Schema Model file DDL SQL Artifacts Compose model representation from source code fragments!
- 21. Target .dbschema Database file Schema Model Schema Model Model Diff Plan Executors .SQL Deployment Additional schema artifacts Engine Incremental Target Update
- 26. Creating New Database Projects Offline Schema Development New Deployment Schema Refactoring Incremental Deployment Schema & Data Comparison
- 33. Dependency Validation TSQL Static Code Analysis Test Data Generation Database Unit Testing TSQL Debugging
- 35. TFS Source Control Check in to DBDev DBA Staging Database Database Import schema Production Project Database
- 36. •Sync Dev •Check-out Env •Edit/Refactor •Generate Test Data •Database Unit Test Dev •Check-in Env TFS •Work is being driven Dev and tracked via work items Env •Other team members can pick up changes DBDev DBA Staging Database TFS Shelving allows DBA Dev to provide guidance Env Production and evaluate work Database
- 37. Daily Test Build Database Output Can also be TFS used in a “Continuous” Get Latest build environment DBDev Daily Build Test Lab DBA Staging Database Production Database
- 38. TFS Sync from Label DBDev DBA Deploy Staging Database SQL Database Deploy Production Project Build Script Database Verify Refine deploy script
- 41. Schema DATABASE SCHEMA Tables Views Constraints Sprocs UDFs Users Logins Filegroups PROPERTIES & METADATA Requirements Management Policies Failover Policies
- 42. Database Project Data-tier Application Project V1 (Mission Critical, Business Critical) (Departmental Apps) Visual Studio Visual Studio Build Build Generate scripts .dbschema .dacpac Deploy Deploy SQL Server 2005, 2008, 2008 SQL Server 2008 R2 & 2008 R2 R2
- 43. DEVELOP DEPLOY MANAGE SQL Server Management Studio FinApp 1 Dev DB Deploy / Reverse Upgrade DAC Engineer DAC 2 SQL Server Management Studio DBA 9 8 Visual Studio 2010 Manage, Register, Uninstall, Extract, Upgrade DAC Control Point Create policies DBA 7 3 Deploy / Upgrade DAC HR Developer Compile Hand-off to DBA + Build FinApp Prod DB 6 5 .dacpac SALES Managed Instances
- 45. SQL Server Version DAC Feature 2000 2005 2008 2008 R2 Azure Extract DAC Yes Yes Yes Yes Yes Deploy DAC No No In SP2 Yes Yes Delete DAC No No In SP2 Yes Yes Register DAC No No In SP2 Yes Yes Upgrade DAC No No In SP2 Yes No SSMS Support No No No Yes Yes (2008 R2)
- 54. http://msdn.microsoft.com/en-us/library/ee210554(SQL.105).aspx http://msdn.microsoft.com/en-us/library/ff381683.aspx http://msdn.microsoft.com/en-us/library/dd193245(VS.100).aspx http://msdn.microsoft.com/en-us/library/ee210580(SQL.105).aspx http://www.youtube.com/watch?v=jmFQrBp6D0g http://channel9.msdn.com/Events/TechEd/Europe/2010/DAT311 http://technet.microsoft.com/en-us/sqlserver/Video/ee795823
Editor's Notes
- #5: Databases are a critical component utilized by many (if not most) software applications. And yet, they are traditionally underserved by tools that can facilitate development, testing & deployment. Database developers are usually left to cobble together disconnected tools for developing & deploying database changes. Furthermore, database developers usually follow a process that is disconnected from the process followed by the application development team, resulting in an error-prone and labor-intensive system of collaboration. With VS2010, you can finally bring the process of managing changes to your database into the same toolset and process framework used by the other members of your software development team.
- #12: Databases are a critical component utilized by many (if not most) software applications. And yet, they are traditionally underserved by tools that can facilitate development, testing & deployment. Database developers are usually left to cobble together disconnected tools for developing & deploying database changes. Furthermore, database developers usually follow a process that is disconnected from the process followed by the application development team, resulting in an error-prone and labor-intensive system of collaboration. With VS2010, you can finally bring the process of managing changes to your database into the same toolset and process framework used by the other members of your software development team.
- #14: For those new to Visual Studio Database Projects, Database Projects provide 3 main pillars of functionality:1.) Managing ChangeVersioning of your database schema – Full fidelity offline schema development of your database within the project systemIncremental Deployment - Deploy your database schema against multiple versions of a database schemaSchema Compare – Database Tooling to compare schemas between databases, database projects, and dbschema (dbschema files which are the primary output artifact of building a database project) Schema Refactoring –Database Tooling to support common iterative changes to your database schema within the development cycle (Refactoring operations include: Expand Wildcards, Rename, Move Schema, Fully Expand Names 2.) Managing QualityDependency validation and visualization –Validation during design and build ensuring consistency and integrity of your database schema Static Code Analysis – Analogous to FxCop, but for SQL. The product has 14 rules that it ships with. The inbox rules cover naming, design, and performance issue categories. Unit Testing and Data Generation – A Unit Testing Framework similar to what is available to the app developer, but with T-SQL and Data Generation capabilities to test your instantiated schema with data.
- #15: 3.) DDLC Integration into ALMTeam Developer brings the database development lifecycle into the Visual Studio Developer experience in a consistent and familiar manner. Many of the same idiom or metaphors now exist for database development that c#/vb.net developers are accustomed to. Database projects bring the data tier developer into the team based development lifecycle. (Define, Design, Develop, Test, Deploy, Manage) Lather, rinse, repeatBuild integration with MSBuild and TeamBuild4.) Database Development Platform ExtensibilityDatabase projects offer extensibility to add features to the project system or to expand features that ship with the productFeature extensibility includes: Custom Static Code Analysis Rules, Custom Unit Test Conditions, Custom Data Generators and Data Distributions, Custom Refactoring Types and Targets
- #17: Can you use a Diff Utility of any Version Control System to get the changes between V2 & V3 for the database ? No
- #18: Not performantError-prone because it’s difficult to get the dependency tracking correctLabor-IntensiveRequire extensive additional logic to account for customizations or versioning differences between different instances of production databases.Database changes must be made in a precise order to preserve the integrity of the schema & prevent data loss.Can introduce additional bugs
- #20: Visual Studio eliminates the need to ever hand-code database deployment scripts.
- #21: Schema Model = In-memory model of the database.Creating database objects & editing TSQL cause visual studio to perform background analysis of your changes & make the appropriate changes to the schema model, it may also detect syntax errors, dependency errors & thus protect the integrity of your database schema.As mentioned we persist our database schema as separate .sql scripts within a Visual Studio project system. Which is a physical container for grouping all of the .sql files that make up a database schemaBecause we are completely offline, and there is no database in place within the Database project system, we also need to understand the database from a logical perspective, namely how each of the object relate, depend on each other.We do that via a Schema Model, which is basically an in memory representation of that database schema as it would exist in a live database.To populate our schema model, we can take an existing database, reverse engineer the definition of that database (no data) and create .sql files for each schema objects(.sql file for each table, .sql file for each primary key, stored procedures etc.).We can then version control those .sql files just like you version control any of your .Net coding filesWith the .sql files, we then load the content of the file through our intrepret component to interpret the schema definition (is this a stored procedure we’re dealing with, or is this a table etc.) and then analyze the content(do we already have an object defined using this name, does this object depend on another object, namely for Primary Keys which table does this pk belong to etc.) and then we validate(is the object defined correctly, for Primary keys is the table defined and in an non error state). Once each of our objects pass this process, we then populate it into our schema model, which provides a true picture of a database which is fully validated and could be deployed to a live database without any semantic errors.The persistent model of the schema model is a .dbschema file
- #22: This is a simplified diagram of how the incremental deployment engine works. In a nutshell, it uses in memory models of the source and target databases to compare schemas to create a deployment plan. The deployment plan produced is dependency and data aware. Examples: Trying to DROP objects that have dependencies not in comprehended in the project will often fail the deployment.Modifying the schema of the database that may introduce data loss is optionally blocked in deployment. Test OK to lose data. Production, not so much. The deployment engine produces a list of differences and a deployment contributor acts on those differences to produce the least invasive approach to modify the target database to match that of the source. The deployment contributor combines this deployment plan with additional project artifacts and generates a SQL deployment script. Additional deployment contributors also act on the database target by emitting additional SQL or supporting artifacts LIKE a change list or data dictionary. We will see more of this later.
- #24: Now you can defer the comparison of the source & target database so that an appropriate script is generated based on the state of the target database.
- #43: The new SQL Server Utility provides an overall understanding of your organization’s SQL Server health as well as resource monitoring. The ideas originally came from consolidation projects and makes applications easier to move around.
- #45: Do Data-tier Application (DAC) projects replace Database projects? A lot of people are currently using database projects—initially, the adoption rate was slow, but it is definitely picking up. This table shows the strengths of each project type. Larger applications are best completed through Database projects. DAC projects add deployment intent and have been optimized for 1000 objects per project in V1. The aim of the DAC project type is to automate the process completely for departmental applications.
- #51: SSDT is the latest investment Microsoft is making in integrated tools for relational database developers targeting Microsoft SQL Server. SSDT is the evolution of Database Projects for Visual Studio, and contains new capabilities and improvements, all accessible within the Visual Studio 2010 Integrated Development Environment (IDE).