Today we have a guest editorial from Kendra Little as Steve is away on his sabbatical.

In the 2020 State of Database DevOps report we see an interesting combination of trends: 

• Frequent database deployments are increasing: 49% of respondents now report they deploy database changes to production weekly or more frequently
• Use of version control for the database has increased only modestly, with 56% of respondents overall reporting that database code is in a version control system 

Digging into the data, we see that not all frequent deployers are using version control. This means that either code changes are being frequently made directly to production databases without the changes being scripted out, or that scripted changes are being stored in file shares or other mechanisms which are less reliable and flexible than a true version control system. 

Combining this data with responses related to code quality, we also see that frequent deployers who report they use version control for database code reported lower percentages of defect rates as compared to frequent deployers who do not use version control for database code. This finding is not surprising to me personally, as in my experience the use of version control provides not only a mechanism to reliably share and review code, but it also provides a strong foundation for testing and validating the quality of changes. 

So why aren’t more teams using version control for database code, and how can they get started? 

We see in the survey data that the two biggest perceived obstacles to implementing DevOps are concerns about the disruption to existing workflows/business and a lack of appropriate skills in the team. Perception is critical here, and I believe that concerns in these two areas are a big reason why people are slow to adopt version control for databases: they worry that people will be slow to learn how to do it, and that this will cause a significant stall for the team and disrupt business workflows and deliverables while things get sorted out. 

The easiest way to overcome these obstacles is to start small and work in incremental changes. This may mean doing things imperfectly to begin with: perhaps the first move your team makes to implement version control for databases is to capture schema nightly and store that schema in version control, while still using your established process for deploying changes. While this doesn’t give you all the benefits of using version control as part of the development process, it gives you the ability to see when schema changes day by day, and it gives your team a way to begin learning how version control works and a way that they can look at trends over time. 

The important thing isn’t to implement the perfect solution right away: the important thing is to get started and to begin to incrementally improve.