1. SSDT, Docker, and (Azure) DevOps
How to Make Your Database Builds a First Class CI/CD Citizen

2. Thanks to our Sponsors

3. What’s On Deck? Why Are We Here? Tools Overview
Unit Testing? In a Database?
Azure DevOps Builds – We Pull It All Together
Questions

4. Why Do We Want To Do This Anyway?

5. First, Some Definitions
DevOps – A set of software development processes that combines software development and information technology operations to shorten the systems development lifecycle while delivering features, fixes, and updates frequently in close alignment with business objectives (Wikipedia)
Continuous Integration (CI) – Integrating into a common branch frequently, building the code, and running automated unit tests to ensure the changes are valid
Continuous Delivery (CD) – Automated release process that allows push button release of the CI artifacts

6. Why Use a CI/CD Process With DDL
Your data definition language is part of your codebase, just like the application code
Practicing CI/CD in conjunction with storing your DDL in source control allows your developers to see changes as they happen and participate in the process
You will share a common development, build, and deployment mechanism with your application developers
You can definitively answer the question “what was deployed?” and can recreate the database shape to any point in time
Building your database can help identify issues such as misspeelings or missing objects

7. Intro (or Refresher) to Our Toolset

8. SSDT Overview What is it? Why would you use it?
SQL Server Data Tools (SSDT) is a component of Visual Studio that allows you to easily organize your DDL, including tables, views, stored procedures, and most other components, and build it to an easily deployable package, known as a DACPAC
For Visual Studio 2017 and 2019, the basic functionality to create database projects is built in; however, SSAS, SSIS, and SSRS projects require an additional plugin
Why would you use it?
SSDT is an incredibly source control-friendly way of storing the shape of your database
Visual Studio is the same tool used by developers
If you have SSAS, SSIS, or SSRS running in your environment, you are already using SSDT
The build artifact (DACPAC) is easily deployable across a wide variety of platforms
You can target multiple versions of SQL Server and gain some assurances that your code will work via the compilation process
SSDT performs syntax checking while you develop, allowing you to catch issues up front

9. Docker Overview What is it? Why would you use it?
Docker is a tool that allows creation and deployment of containers
Containers allow you to host only the parts of the OS that are absolutely necessary for running an application
Essentially, Docker allows for the flexibility of Virtual Machines without the large overhead
Why would you use it?
Containerization allows applications to scale quickly and flexibly
By utilizing containerization, you can upgrade parts of an application without taking the whole application down
Containers are generally lighter weight and require fewer resources than a full VM would, and they are easy to bring up and down, allowing for conservation of server (or developer machine) resources
Containers are portable. The container you run on your desktop can be easily run in AWS or Azure
Microsoft makes SQL Server available in a Docker container, simplifying development and allowing you to isolate each database in development

10. Azure DevOps Overview What is it? Why would you use it?
Azure DevOps is Microsoft’s build and deployment automation tool
It also offers source control and work tracking capabilities
Microsoft offers both on-premise and cloud versions, although they prefer you to use the cloud version
Azure DevOps was previously known as Visual Studio Online and is the evolution of Visual Studio Team Services and Team Foundation Server
Why would you use it?
Azure DevOps offers a top to bottom DevOps tool
It integrates well with the Microsoft ecosystem, including Azure
Azure DevOps provides native ways to build and deploy Microsoft stack-based applications, including SQL Server
The range of options for deployment (including using the cloud version with your own build server) are compelling

11. Unit Testing?

12. Unit Testing???
If you have business logic in your database, it needs to be tested somehow
The output of functions and stored procedures can change (or stop working entirely) with DDL changes
Using the tSQLt unit testing framework ( can help detect regressions in your code
But…unit tests can only be effective when you run them, preferably in an automated fashion

13. Azure DevOps Builds

14. Things We Can Do To Improve and Extend This
Have a dedicated build server
As you have seen, the build is very slow using only Azure-native components
Handle data type changes
This potentially involves both a pre-deployment script (to copy data out of the affected table) and a post-deployment script (to copy data back into it)
These scripts will need to test whether the change is in place or not

15. What This Doesn’t Solve For

16. Some Things This Doesn’t Solve For (Directly)
Large-scale refactorings
Load testing
Cases where you need to specify a version in the database itself
This is probably possible, but would require some serious scripting
Your thoughts?

17. Questions?

18. Who am I? Dan Mallott Twitter: @DanielMallott
Github:
LinkedIn:
Principal for West Monroe Partners
In the industry since 2011
Primary experience with SQL Server, starting with SQL Server 2005
Also worked with Oracle, PostgreSQL, and Cassandra
Been both a DBA and a developer
Have a couple Microsoft certifications
DataStax Certified Professional