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

Thanks to our Sponsors

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

Why Do We Want To Do This Anyway?

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

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

Intro (or Refresher) to Our Toolset

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

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

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

Unit Testing?

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 (https://tsqlt.org) can help detect regressions in your code But…unit tests can only be effective when you run them, preferably in an automated fashion

Azure DevOps Builds

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

What This Doesn’t Solve For

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?

Questions?

Who am I? Dan Mallott Twitter: @DanielMallott Github: https://github.com/danielmallott LinkedIn: http://lnked.in/danmallott 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