Managing Database Change in Source Control

  • Article

This post demonstrates two methods for managing database changes in source control with SQL Server Data Tools.

The standard integration that you would find with any project type in Visual Studio is all there for SSDT Database Projects, but C# developers have it easy – there is only one place to make changes, and that is the source-controlled code itself. But you, database developer, have a live database to deal with! How do you achieve a rapid edit and verify loop with a live database and a source-controlled database project?

There are two primary methods you can use in SSDT, depending on your preference. Let’s say you want to create or change a Stored Procedure, verify it works as expected, and then check it in.

Method 1: Start with the Project

Edit objects in the database project and use the debug database to verify changes before checking in. This is the safest method since the testing is isolated from any production environment.

  1. Specify a debug database for the project in Project Properties -> Debug tab -> Target Connection. By default, this sets up LocalDB for you, but you can use any other database connection. For example, use a test database that is kept in sync with the production database with test data. Find more details on using LocalDB here: https://blogs.msdn.com/b/ssdt/archive/2012/06/06/getting-started-with-localdb-debugging-using-ssdt.aspx
  2. In SQL Server Object Explorer (SSOX), go to the debug database and View Code for the Stored Procedure you want to change, or Add New Stored Procedure. This opens the project source code for that procedure. Make your edits.
  3. There are a few options to verify your changes before checking in the Stored Procedure.

Option 1: Execute directly. Right-click in the Editor and you can execute in place against the debug database. For example, highlight portions of T-SQL and Execute as you build up a query.

Option 2: Hit CTRL+F5 from the project to deploy changes to the debug database. Through SSOX, right-click the Stored Procedure and Execute. You can set a breakpoint within the Stored Procedure to debug.

Option 3: In the project, add a new Script (Not in Build) that executes the Stored Procedure. In Project Properties -> Debug tab -> Startup Action, set the new script as the Startup script. Hit F5. This will deploy and run the Startup script with the debugger, allowing you to verify the Stored Procedure.

       4.  Once verified, check in the Stored Procedure file in your project.

At this point, you have the right code in source control, and can push the change to production in your preferred way (Publish, Schema Compare, SqlPackage.exe).

Method 2: Start with the Database

If you prefer to edit and verify directly connected to your target database, you can still easily get the changes checked in to source control.

  1. In SSOX, View Code on the Stored Procedure you’d like to change or Add New Stored Procedure. Make your edits. Click Update in the object editor to push the changes to the live database.
  2. Right-click the object in SSOX, and choose Execute Procedure or Debug Procedure to verify.
  3. Once verified, use Schema Compare to pull the changes back into your source-controlled database project. Set up the Schema Compare with the database as Source and the database project as Target. You can save the Schema Comparison (.scmp) to your project to make this step even faster for subsequent iterations. After updating the project with the new Stored Procedure, check it in!

At this point, you have the right code in your database and in source control.

 

 

Note: If you use SSDT stand-alone, without a full Visual Studio 2010 SKU, you can still integrate with source control providers!