1. Continuous Deployments using SSDT
How I Learned to Stop Worrying and Love the DACPAC

2. Who am I?
Christopher Wolff
Blog:

3. Objectives Continuous Deployments Of DACPACs and Publish Profiles
SqlPackage.exe and you!
Using your tools
Automation Nation
Questions?

4. Assumptions
Basic knowledge of SQL Server Data Tools for Visual Studio (SSDT)
Basic knowledge of XML for Publish Profile manipulation
Basic knowledge of how a relational database schema works
Specifically Microsoft SQL Server in this case

5. Continuous Deployments
Synergizing synergies

6. Why Continuous Deployments?
To cut down on the amount of code in each release
Makes sprints shorter and is easier to troubleshoot issues on release
Give development team ownership of there own releases
Take Ops out of the way so if issues arise, the development team can troubleshoot the issue first and then use Ops as a last resort
Catch issues earlier in the process
Testing is done constantly during development instead of at the end so fixes are done right away instead of waiting for the next sprint

7. Steps for Continuous Integration
Every developer will have a version of the DB on there own machine
In order for them to have ownership, they must test it themselves
It’s also good to do pull requests so the fellow developers can check each others work
When they are complete with their individual tasks they check the SSDT project into a source control system
Github or Team Foundation Server
A deployment manager or project manager will typically make an integration branch in the source control
This is for teams to commit their finished code to before the release happens
Typically this will also deploy to a Stage environment so that QA can do further testing
Once a release has been declared, the manager will make a release branch
All changes will then be merged to this branch in preparation for the release to Prod

8. On to Continuous Deployment
Once all code has been merged deploy the code to a testing environment
Often called Livestage or just Test
It will contain a recent version of a prod backup to test against live data
QA’s commences testing
This usually happens a week before release so QA can flesh out any issues
Release to Live

9. Of DACPACs and Publish Profiles
Tools of the trade

10. DACPACs Data Tier Applications
Contains all the schema information in any one database
Gives a single entity for deploying changes to a production or test database
As apposed to multiple SQL scripts
Can also include security credentials if needed
Idempotent so they will never rerun code, just the code that is missing
A close relative is the BACPAC which contains all the data in the database along with the schema information

11. Publish Profiles
A collection of all the property key-value pairs that are used by the DACPAC as settings when deploying to a target database
Include properties like:
Database name
Connection string
SQLCMD variables
How to handle change data capture (CDC) and replication
All of these properties come from SqlPackage.exe

12. SqlPackage.exe and you!
The one .exe to rule them all

13. SqlPackage.exe
A command line tool provided by SQL Server that automates extraction, exporting, importing, publishing, and scripting of a database
It is automatically installed with every version of SQL Server
Usually stored in C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin
Built in parameters that switch on or off the property of the deployment
Examples
/p:IgnorePermissions={True | False} - Specifies whether permissions should be ignored during deployment.
/p:DoNotAlterChangeDataCaptureObjects={True | False} - If true, Change Data Capture objects are not altered during deployment.
/p:DropObjectsNotInSource={True | False} - Specifies whether objects that do not exist in the database snapshot (.dacpac) file will be dropped from the target database when you publish to a database.

14. Using your tools
How to do the needful

15. Basic Setup Have a deployment server to dispatch the code from
Typically called a terminal server
Have the dacpac and published profile checked into a versioning system
Such as Github or Team Foundation Server
Using SQLPackage.exe, execute a command line script to publish the dacapac and publish profile to the server
Example
"C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\SqlPackage.exe" /a:Publish /TargetConnectionString:"application name=DBDeployment;data source=MyProdDB;initial catalog=MyProdDB;Integrated Security=True" /SourceFile:"C:\Deployment\Input\1.0\MyProdDB\MyProdDB.Database.dacpac" /pr:"C:\Deployment\Input\1.0\MyProdDB\MyProdDB.Database.publish.xml“
When you execute the scripts it will print a log file to the screen of what was actually executed in the dacpac
Optionally you can have it output to a log file instead
> "C:\Deployment\Output\1.0\MyProdDB\ _0700_MyProdDB_1_0.log"

16. DEMO

17. Making your job easier, one script at a time
Automation Nation
Making your job easier, one script at a time

18. Why Automate? Consistency Less Errors Speed and Ease of Use
Using the same release process every time will cut down on errors
Less Errors
Makes it easier to troubleshoot and quicker to recognize where the errors occur
Speed and Ease of Use
Single call to execute the release as apposed to running multiple scripts

19. Automation Tools Source Control Continuous Integration Software
GitHub
TFS
Continuous Integration Software
TeamCity
Jenkins
Bamboo
Octopus Deploy
Scripting software
PowerShell
Ruby
Bash
Cmd Line

20. Steps to Automate Check in Release Check for New Release
Usually through a release branch in the source control software
Check for New Release
The CI software can be used to look for new releases in source control or have a release manager initiate the release through the CI software
Run the Release
The CI software will then run the predesigned script to deploy the release

21. Questions?
Comments?
Crude remarks?

22. Credits Data-tier Application Overview
Publish Profile Files in SQL Server Data Tools (SSDT)
files-in-sql-server-data-tools-ssdt.aspx
SqlPackage.exe
Deploying a DACPAC with SqlPackage