“DevOps” is a broad term which encompasses various disciplines like CI / CD, testing, monitoring and more. Donavan Brown’s classic post states: “DevOps is the union of people, process, and products to enable continuous delivery of value to our end users… You cannot buy DevOps and install it. DevOps is not just automation or infrastructure as code. DevOps is people following a process enabled by products to deliver value to our end users”. In this post, we take a non-opinionated look at what DevOps for Azure SQL looks like, by reviewing common concepts and providing some options for implementing DevOps for Azure SQL.

Personas

If you consider DevOps in a typical organization, several personas emerge:

• Security and Compliance – typically responsible to define security controls and patterns
• Central IT – responsible for defining environments (dev / pre-prod / prod) and acceptable infrastructure patterns (including networking)
• Operations – manages pipelines and software releases
• Development – implements line-of-business applications

All these personas have a role to play when it comes to DevOps for Azure SQL. For example, what we classically refer to as “DBA” or “Data Engineering” roles tend to span the Operations and Development personas mentioned above. In the sections below, you will see correlations of technology and process to these personas.

Database Lifecycle

Let’s quickly consider the lifecycle of a database:

• A database is created as a collection of schema objects (tables, views, indexes etc.) and programmability objects like stored procedures, functions etc.) It is possible to represent all of these as code which can then be version controlled and subjected to “operations” conceptually like any other application code
• In the past, it was common for database development to be done in a “connected” fashion where database management tools would be used to create database objects. The database itself would serve as the system of truth
• Over time, the availability of database design tools and / or object-relational mapping libraries have caused most of the database development to happen inside a development environment of some sort. Accompanying this has been the tighter integration of database development practices with “traditional” app dev practices – source control, automated testing, code reviews, release management etc. This is where most of this blog post will focus on.
• When talking about changes and releases to databases, it is important to also consider what makes database operations slightly different from “regular” application code: in addition to the “code” (schema and programmability objects), a database also has state in the form of data stored in it and as the data stored conforms to the schema of the database objects, any changes to those objects typically impacts data. This is what makes operations on a database more challenging than the usual.
• Lastly, the broader database lifecycle (out of scope for this blog post) encompasses critical activities like performance monitoring, iterative tuning of queries and much more. There’s excellent coverage of this broader view of Database Lifecycle Management in this series of community posts from Redgate.

Developer Experience

There are two common approaches when it comes to implementing changes in a database:

• Declarative or state-based approach: the developer specifies the end state of the database, and lets the tooling figure out how to incrementally update a given target database to bring it to that end state
• Imperative or migration-based approach: the developer (sometimes with help from some tooling) creates an incremental script (or set of scripts) which implements the change

#azure sql #devops #azure devops #developers #github