Starting with SQL Server 2008, Microsoft introduced a new project type called Database Projects. These projects use the state-based approach to applying changes to your database. Initially, Database Projects were not available as part of the initial Visual Studio install and had to be downloaded separately. This download was referred to as SQL Server Data Tools (SSDT) and included project types for Database projects, SQL Server Reporting Services (SSRS) projects, and SQL Server Integration Services (SSIS) projects. Modern versions of Visual Studio have SSDT available to choose when installing or modifying an existing installation.
Installing SSDT for Visual Studio
For earlier versions of Visual Studio such as 2015 and below, installing the SSDT was a matter of locating the download for your version of Visual Studio. Microsoft has provided a convenient way of finding the appropriate download on this page.
For more modern versions of Visual Studio (2017+), checkout Microsoft’s installation instructions
This guide uses Visual Studio 2019
Connect the project to the database
With SSDT for Visual Studio installed you can connect the project to the database with the following steps. First, we create the project:
- Navigate to the Other Toolsets category.
- Click the Data storage and processing option.
- Select SQL Server Database Project and click Next.
- Enter the project name and click Create.
The project has been created, now we connect it to a database. This example uses a pre-existing database called OctoFXDemo:
- Right-click the project name, then click Import ➜ Database.
- Click Select Connection.
- Add the Server Name and select the type of authentication. In this screenshot, a SQL Account is used to connect to the database server.
- Click Connect and then click Start to import the database.
Importing the database will populate your project with the existing objects from the database. You will see a summary of the importing process:
The project is now ready for creating database schema objects (tables, views, stored procedures, etc…)
Compare the project to the database schema
When the project has some objects, we can compare the project to the target database.
- Right-click on the project and choose Schema Compare….
- Select the target database connection by clicking Select Target ➜ Select Connection, and select the connection.
- Click Compare.
Visual studio will now compare the project to the database and list the steps it will take during a deployment:
For databases that have a dependency on other databases, it is possible to add a reference to another database project. This should be done with caution to avoid circular dependencies with each database depending on each other, as this will result in neither database project compiling.
Build definition
You can use most build servers to build the SQL Server Database project, you just need to install the Visual Studio build tools for the version of Visual Studio that you’re using on the build agent.
This guide uses Azure DevOps as the build platform, but any build server can do this.
Create the build definition
To create the build definition, take the following steps:
Note, this example uses the classic editor without YAML.
- From the Azure DevOps repo, click Pipelines ➜ New Pipeline.
- Select Empty job to start.
- Choose a build pool, then click on the + to add a step to the build definition.
- Click on the Build category and scroll down to Visual Studio build.
An MSBuild task will accomplish the same thing
- Add
/p:OutDir=$(build.StagingDirectory)
to the MSBuild Arguments so that the built artifacts are separated from the source code.
- Click on the +, select Package, and select Package Application for Octopus.
The Octopus Deploy extension is available in the Marketplace, install the extension if you haven’t already done so.
- Add the properties for the task:
- Package ID: Give the package a meaningful name.
- Package Format: Chose whichever package type you wish.
- Package Version: Use the build server build number to associate a package version back to a build number.
- Source Path: This will be the same path as what we set the MSBuild argument to,
$(build.StagingDirectory)
. - Output Path: Location to store the created package.
For Azure DevOps, the build number can be formatted on the Options tab under Build number format. This guide uses the format $(Year:yyyy).$(Month).$(DayOfMonth).$(Rev:r)
.
- Expand the Advanced Options section and add:
- Include: The only file we need for deployment is the .dacpac itself. Add the filename here, this example uses
OctoFXDemo.dacpac
.
- Include: The only file we need for deployment is the .dacpac itself. Add the filename here, this example uses
- The final step in the definition pushes the package to a repository. This guide uses Octopus Deploy’s built-in package repository. Click on the +, select Package, and select Push Package(s) to Octopus.
- Next, create a connection to the Octopus Server, by clicking + New and add the connection details, then click OK.
- Select the space in your Octopus instance to push to from the drop-down menu.
- Enter the package(s) that you would like pushed to the Octopus repository and the individual packages or use wildcard syntax:
- Individual packages, for instance,
$(build.StagingDirectory)\OctoFXDemo.dacpac.$(Build.BuildNumber).nupkg
- A wildcard
$(build.StagingDirectory)\*.nupkg
.
- Individual packages, for instance,
Queue the build to push the artifact to the Octopus Server:
Create the Octopus Deploy project
Now that the build server has been configured to push the artifact to the Octopus Server, we need to create a project in Octopus deploy to deploy the package.
- From the Octopus Web Portal, click the Projects tab.
- Select the Project Group and click the ADD PROJECT.
- Give the project a unique name, a description (optional) , select the Project Group and the Lifecycle, and click SAVE.
Define the project variables
- Click Variables from the project’s overview screen.
- Define the following variables:
Project.SQLServer.Name
Project.SQLServer.Admin.User.Name
(optional)Project.SQLServer.Admin.User.Password
(optional)Project.Database.Name
Project.DACPAC.Name
It is considered best practice to namespace your variables. Doing this helps prevent any variable name conflicts from variable sets or step template variables. Prefixing Project.
to the front indicates that this is a project variable.
If you’re using Integrated Authentication with Windows, you do not need either of the Project.SQLServer.Admin*
variables.
Note, both Project.SQLServer.Admin.Password
and Project.SQLServer.Name
have multiple variables that are scoped to different environments. Learn more about scoping variables.
Define the deployment process
With variables defined, we can add steps to our deployment process.
-
Click the Process tab.
-
Click ADD STEP.
-
Search for
dacpac
steps, select the SQL - Deploy DACPAC using SqlPackage step, and enter the following details:- DACPACPackageName: The name of the dacpac file. The
Project.DACPAC.Name
variable was created for this field. - Publish profile name: Complete this field if you use Publish profiles.
- Report: True.
- Script: True.
- Deploy: False.
- Target Servername:
Project.SQLServer.Name
variable. - Target Database:
Project.Database.Name
variable. - Authentication type: Choose the authentication for your use case.
- Username:
Project.SQLServer.Admin.User.Name
variable (used only with SQL Authentication type). - Password:
Project.SQLServer.Admin.User.Password
variable (used only with SQL Authentication type). - DACPAC Package: The package from the repository, OctoFXDemo.dacpac for this guide.
- Command Timeout: Override the default script execution timeout.
- SqlPackage executable location: If you have the sqlpackage.exe installed, specify the location, otherwise, leave blank to dynamically download it.
- Additional arguments: Any additional sqlpackage.exe arguments not provided by the template.
- DACPACPackageName: The name of the dacpac file. The
-
Add a manual intervention step, scoped to production, so the report from the previous step can be examined before deploying to production.
-
Add another SQL - Deploy DACPAC using SqlPackage step, and change the Report and Script values to
False
, and the Deploy value toTrue
.
The deployment process should look like this:
Create and deploy a release
- Create a release by clicking on the CREATE RELEASE button.
- Click SAVE.
- Click the DEPLOY TO DEVELOPMENT button.
- Finally, click DEPLOY.
The results will look like:
The first part of this process gathers the changes and creates two artifacts, an XML file that reports which objects will be changed and the script it will use to apply those changes. The deployment (deploy DACPAC) uses that generated script and applies it to the target so the database matches the desired state.
Help us continuously improve
Please let us know if you have any feedback about this page.
Page updated on Monday, August 19, 2024