1
How to improve and
extend SQL Server Data
Tools with Red Gate tools
2
Summary
Microsoft SQL Server Data Tools (SSDT) help developers use best
practices, such as Agile development, for databases.
However, SSDT is tightly linked with other Microsoft technologies. It
also enforces ways of working which may not suit all teams.
Red Gate’s tools extend SSDT so teams can use non-Microsoft
technologies, and choose how they prefer to work.
SSDT only
Red Gate tools + SSDT
Develop in Visual Studio
Develop in Visual Studio or SQL Server
Management Studio, the most popular platform
for SQL Server development
Works best if you use Microsoft's Team
Foundation Server (TFS) for version control
Works well with proprietary or open source
version control systems, including TFS,
Subversion, Git, Mercurial, & Vault
Requires developers to work with individual
copies of a database
Lets developers work with an individual copy, or
a single, shared database, which is simpler if the
production database is hard to replicate
Version control for schema changes only
Version control for schema changes and static
data changes
Limited support for automated deployment
Allows deployment straight from version control,
and automatically includes migration scripts to
safely handle complex changes
3
The background
Changes in the software development landscape, such as the rise of Agile, are creating
pressure to deliver software faster. There are great tools to help with this for applications, but
databases have lagged behind.
To meet this need in database development, Microsoft introduced SQL Server Data Tools
(SSDT) and Database Projects. These offer a simple project structure that lets application
developers build and modify database schemas in Visual Studio alongside the rest of their
code. They’re also tightly integrated with Team Foundation Server (TFS), which begins to
simplify deployment.
If you’ve invested in Visual Studio and TFS, SSDT can go a long way to improving change
management for new projects. But on its own it doesn’t suit all teams, because it enforces
certain ways of working.
By using Red Gate tools alongside SSDT, you can work with a wider range of projects and
configurations, continue to develop existing codebases without significant refactoring, and
improve automation and deployment.
Flexible tooling to work the way you want
SSDT delivers the most benefit if development teams work in a few fixed ways:
•
in Visual Studio
•
with TFS
•
with each developer having a sandboxed database instance
The SQL Developer Bundle gives you extra flexibility, and means you don’t need to change the
way your developers and your organization work.
Visual Studio or SQL Server Management Studio?
Using the best tools for the job
Development teams are often formed from a combination of application and database
developers.
Application developers, or those who regularly work on a combination of application and
database code, may like to work in Visual Studio. However, database developers may strongly
prefer to work in SQL Server Management Studio (SSMS), as it better supports
4
SQL development. It also has a wealth of add-ins to make development easier. SQL Prompt
and SQL Search, for example, integrate with SSMS to improve productivity. SQL Test
enables T-SQL unit testing, based around the popular tSQLt open source framework.
Used on its own, SSDT requires all developers to work in Visual Studio.
Red Gate tools allow development to happen across the two environments, helping
development teams work efficiently and without disruption. SQL Source Control connects
SSMS with your source control repository, allowing changes made in SSMS to be shared
with Visual Studio users, and vice versa. You team can work how they prefer – against a live
database or on scripts in Visual Studio.
Version control systems
SQL Source Control supports TFS, Subversion, Git, Mercurial, Vault, and any source control
system with a command line interface, so your SSDT implementation doesn’t have to
mean changing version control system. You can get the benefit whether you’re using TFS
(recommended with SSDT) or any other system.
Local and shared databases
In SSDT, changes are made to SQL scripts, and then deployed to a local database for
testing. This could result in changes not being deployed to a realistic environment very
frequently, but it follows a model similar to application source control and many teams
like it. Others prefer to work under a shared model, where multiple developers modify the
same database. This often occurs when teams have environments that are hard to replicate
realistically.
Red Gate tools support both shared and individual development databases. Again, this
extends the capability of SSDT to meet the specific needs of your team.
Getting the data right
With SQL Source Control you can source control and compare reference data (static data,
lookup data, and configuration data).
SSDT doesn’t support static data – it’s focused on schema changes. But lookup data in
particular can change with your business logic, so it’s good to have it tied to your database
development. SQL Source Control bridges the gap, letting you check static data into source
control, so it’s versioned alongside schema changes, and you can include it automatically
with deployments.
5
Red Gate also provides highly customizable data generation, through SQL Data Generator.
This means you can test your changes on realistic data when production data is not
available, for example, if it’s sensitive customer information or financial data. Adding this
capacity to SSDT enables more accurate testing, and lets you include reference data in
automated deployments, removing the need for post-deployment changes.
Robust, repeatable deployment
and continuous integration
In SSDT you can deploy changes to a local database instance from Visual Studio, or create
a DACPAC that can be deployed via SSMS or SQLPackage. This works well, but can be
improved. In particular, Red Gate tools help you increase reliability and ease of automation
when you would need customization and pre- or post-deployment scripts.
Most commonly, that’s when schema changes require data manipulation, such as with table
and column splits, merges and renames, data format conversion, or adding NOT NULL
columns without a default. Comparison tooling can’t guess the intent of your changes, so
you need to add scripts as a workaround. It’s messy and less robust for automation.
Red Gate tools can automatically incorporate migration scripts when you deploy schema
changes. Your deployment scripts can therefore be run automatically (for example in
continuous integration) without needing manual intervention; or, you can handle them
manually, reviewing a whole deployment for QA, without fear of data loss or the need to
review multiple scripts without context.
The command line versions of SQL Compare and SQL Data Compare can be used to
automate deployments from source control, so you can set up continuous integration for
your database changes, whatever your source control and build system.
For more information, see our whitepaper, Continuous integration for databases using
Red Gate tools
Whitepaper
Continuous integration for
databases using Red Gate tools
A technical overview
6
your changes
SQL Compare and SQL Data Compare are the market leading, industry-standard tools for
comparing and deploying SQL Server changes. In fact, 70% of the Fortune 100 use SQL
Compare. These tools let you see database changes quickly, easily, and in detail, as well as
letting you create reports.
Unlike deploying with a DACPAC, you can review and edit the deployment scripts
generated by SQL Compare and SQL Data Compare, or use them to verify the state of
your environment after an automated deployment. The reporting functionality can itself
be automated via the command line interface, giving you a clear history of what schema
changes have been made.
Project is being deployed reliably to each environment, without error or data loss.
Conclusion
If you’re using Database Projects and SQL Server Data Tools to make your database
changes, Red Gate tools can help you minimize the disruption to your team, and improve
the reliability of automation and deployment.
Developers who prefer to work on SQL scripts in Visual Studio can work side by side with
those working connected to a live SQL Server database in SQL Server Management Studio.
control.
The Continuous integration for databases using Red Gate tools Whitepaper
7
All the Red Gate tools outlined in this document are available
as a free trial, or you can get in touch to arrange a demo.
SQL SOURCE CONTROL
Helps maintain database schema and data in a source control system within SQL Server
Management Studio
Allows for the creation of custom migration scripts which are saved to source control
SQL COMPARE & SQL DATA COMPARE
Create a database from source files in version control
Generate schema and data deployment scripts
Validate that two databases are identical
Generate pre/post-deployment reports for troubleshooting
SQL TEST
Allows developers to easily create, run, and manage tSQLt unit tests on databases
SQL DOC
Generates the latest database documentation automatically as part of your CI process
SQL PROMPT & SQL SEARCH
Productivity plug-ins for SQL Server Management Studio
SQL Prompt provides code completion, formatting, and help with refactoring
SQL Search finds fragments of SQL inside stored procedures, functions, views, and more
SQL DATA GENERATOR
Generates realistic test data based on your existing schema
SQL AUTOMATION PACK
Command line versions of the tools in the SQL Developer Bundle