How to deploy SQL script to clients

Question

Our company is in the process of adapting TFS for source repository and project management. I am in charge of database part of the project. We are using SQL Server 2008 R2, Visual Studio 2012 and TFS Online. We have a database that is used by several of our applications. So far I have been the only one handling any change to this database. As the company is expending we are going to have multiple dev teams. So I am planning to save the database as as SSDT project to TFS.

At the moment I am maintaining my database like the following:

• I have separate folders for UDFs, Stored Procedures, and Config.
• Under these folders I have subfolders for each objects. For example, for stored procedures I have subfolders for each stored procedure which contains the SQL script to create the SP. The config folder contains any script similar to SSDT's post deployment script (for example, populating static data).
• The SQL script contains code to drop the procedure and create it.
• I have a c# app to concatenate all the SQL files into one single SQL file. Let's call it the FINAL script. When creating FINAL script I can specify version number which adds an update statement to update the version table on the database.

FINAL script is made available for customers to download and execute on the database. So the script mainly contains any add/edit to SPs, UDFs, and static data. It does not touch any existing data (data entered by user) in most cases.

As a newbie to TFS and SSDT I am not exactly sure how this can be done using SSDT/TFS or if there is better way of doing something similar. So far what I have understood about SSDT and TFS is:

• I can import an existing database to SSDT project.
• This will create scripts for all objects including tables.
• I can easily do a publish of the database to a local server or to a server I have access to.

Things that seem confusing so far:

• How do I supply clients with my latest update script? I am thinking of manually including the FINAL script to the SSDT project but there must be better way of doing it.
• How do I publish the changes to a copy of the database without the loss of any user-entered data? My guess is when publishing the tables get created. I can take care of the static data but I am not sure how to handle data entered by users.

May be there is something fundamentally wrong in my understanding of this whole thing. That is why I am here... :)

Answer 1

You want to pull your DB into a SQL Project. Maintain all of your changes there. This tells your system what the schema of your database should be. From there, I'd generate the dacpac files (through building the project) and provide those to your clients along with having them install the SSDT tools that include SQLPackage. They can run SQLPackage to make changes to their database to handle the schema changes automatically. This will bring their database in line with your schema, no matter how far off it might be.

I'd also create a publish profile for them to use. This lets you control some of the settings.

• You can choose to not drop any objects not in your project
• You can choose to ignore users/permissions
• You can set an option to not allow changes if there would be data loss.
• You can wrap everything in a transaction so a failed update rolls back
• If you give them a batch file to run, you can specify an output file or a Diff report, or have them generate their own script to do the update.

I blogged about this at http://schottsql.blogspot.com/2013/10/all-ssdt-articles.html (or http://schottsql.blogspot.com/search/label/SSDT if that doesn't work well). That will take you through some basics of why you might want to use SQL Projects, creating them, maintaining them, and publishing the changes to an existing database.