Deploying Databases Has Never Been Easier!

There are several approaches to SQL Server database development and Database Lifecycle Management (DLM). These approaches range from specialized tools and project types to the storage and cataloging of SQL scripts and everything in between. However, for true DLM, that encompasses all the phases, from development to deployment there are three main options.

Option 1: SQL Server Database Projects (Visual Studio)
This is a natural approach for developers who prefer to use Visual Studio. Visual Studio uses an “offline” approach to database development where changes are made to local files and then can be tested with a local in-memory instance of the database. The Visual Studio build process creates a Data-Tier Application called a DACPAC. A DACPAC contains xml files representing the schema of the database. Changes are deployed by “publishing” the DACPAC to a target database. Visual Studio DACPACs do not support data changes, which must be managed separately. They also do not handle cross database dependencies very well. However, for single database schema changes they are very effective. There are VSTS/TFS deployment tasks that consume and publish the changes contained in a DACPAC to a target server.

Option 2: Redgate SQL Source Control and SQL DLM Tools
Redgate provides a variety of database development tools. The first, and the basis for most of the remaining toolset is SQL Source Control. SQL Source Control integrates with many source control providers such as TFS/VSTS (either TFVC or Git), Git, SVN, Perforce, Mercurial as well as many others. There are some significant differences between SQL Source Control and the other options. First is that SQL Server Management Studio (SSMS) is the primary tool instead of Visual Studio. Additionally, with SQL Source Control, a physical database becomes the effective workspace for development. This is a natural choice for SQL Developers who are used to and/or prefer using SSMS instead of Visual Studio. Changes are made to a database that is linked to source control and those changes are committed to source control. In a VSTS/TFS environment, the committed changes can also be easily associated with VSTS/TFS work items.

SQL Source Control is a very mature tool that handles a variety of database changes. Non-volatile lookup tables’ data can also be linked to source control as well as the table schema which is a huge advantage.

Since the objects stored in source control are all stored as .sql files, they can still be opened and modified in any text editor, including Visual Studio. Changes can then be applied to the workspace database through a Get Latest operation, just as you would in retrieving the latest code changes on any application. Redgate also provides build and deploy extensions that can be used with VSTS/TFS, TeamCity or Jenkins to easily configure automatic database builds and deployments.

Option 3: Ready Roll SQL Server Database Projects (Visual Studio)
ReadyRoll is also a Redgate product, but a lightweight version of the tool, ReadyRoll Core, is now included with Visual Studio 2017 Enterprise.  As a compromise between SQL Source Control and Visual Studio SQL Server Projects, ReadyRoll uses a third technique for handling database changes. ReadyRoll creates migration scripts for changes to either a physical database or database schema objects. Since it works in Visual Studio, all changes can be tracked and linked to source control. The resulting project type is essentially a package of scripts with a numeric prefix that are run in order against a target database. It’s a blending of old-school and new school SQL development.

ReadyRoll projects handle more complex changes that ordinary DACPAC based projects stumble on., such as cross-database dependencies and updates to data structures. The full version, called ReadyRoll Pro, is available from Redgate. It also integrates with Visual Studio, but supports additional features such as the ability to link and manage changes to data. ReadyRoll uses the standard Visual Studio build task, but uses a custom ReadyRoll deploy extension. The extension is available on the Visual Studio Marketplace to provide the functionality for VSTS/TFS to deploy the project and execute the migration scripts to target databases.

None of the options are exclusive. They can be mixed and matched in the environment, but doing so my complicate your database management a little. In my experience, the biggest deciding factor between the three is what tool you want to use for your database development efforts. If, like me, you prefer working with SSMS and a live database, then Redgate’s SQL Source Control is probably your best bet. However, if the offline approach and Visual Studio are your preferred methods you now have a choice between classic DACPAC based database projects and ReadyRoll’s script-based solution.