Introduction to CI/CD for DB
This is the first post in a series we’re calling CI/CD:DB.
This post is the first in a series where we will talk about the steps required to bring databases into a Continuous Integration / Continuous Delivery (CI/CD) pipeline. The discussion here is not about simply wrapping a bunch of scripts and running it from a “CI/CD” automation tool, but rather about truly leveraging the practices of CI/CD to significantly improve the flow of changes through your delivery pipeline with all of the quality and guardrails that are intrinsic to a well-architected modern pipeline.
The pattern for setting up such a pipeline is well established. Continuous Integration (CI) as a named engineering practice is about 20 years old and Continuous Delivery (CD) is solidly over 10. The combination of the two as a unified topic has been a central driving practice of the DevOps movement over the past decade. However, that conversation has been focused primarily on flowing application code and, to a lesser extent, infrastructure definitions through pipelines to rapidly deliver new functionality to application systems. Conspicuously absent from most of the conversations are the changes to the databases that underlie the applications.
Why is the database left out?
There are a lot of theories for why databases got left out of the CI/CD discussion. Most of them revolve around the notion that databases are stateful and, by nature, persistent while CI/CD is focused on the more ephemeral components of the application stack and is therefore not appropriate for, or even applicable to, databases. The problem with this perspective is that there is nothing in the underlying principles of CI/CD that are not applicable to database change management.
CI/CD for databases
The book Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble, and Gene Kim defines CI/CD as a set of capabilities that enable organizations to get changes of all kinds into production “safely, quickly, and sustainably”.1
The book goes on to list five principles that are central to the practice of CI/CD all of which are as applicable to database changes as they are to application changes:
- Build quality in
- Work in small batches
- Computers perform repetitive tasks; people solve problems
- Relentlessly pursue continuous improvement
- Everyone is responsible
To be fair, the implementation of CI/CD for database changes does look very different and it can be hard to find clear guidance on how to overcome those differences. The purpose of this series is to provide the missing knowledge and guidance to help teams begin solving these problems for their situations. The approach will be to break down a typical pipeline into primary phases, move systematically from “left” (change creation) to “right” (production), and systematically address the main challenges you will encounter.
Hopefully, you will find this series of blogs helpful and come along for the ride! Next blog in the series: Perspective on your pipeline.
1 Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, by Nicole Forsgren PhD, Jez Humble, Gene Kim; p 42
Automate BigQuery schema change and version control with database DevOps
Google's BigQuery is a fully managed, serverless cloud data warehouse, or database as a service (DBaaS), that brings unparalleled scalability and convenience to data analytics.