Its no doubt that everyone has heard the value in implementing Dev Ops in their organization. I consult with a variety of companies trying to get on the bandwagon and get there Devs and Ops folks working together. I noticed that in everyone of these there is a team that is left out usually. That is the Database team. I am yet to here a company who vie worked with ask about database devops. Its a suggestion I always make and I get similar responses. “Our database team works fine” or “We don’t do auto deploys”. This is being really short sighted since the DBAs and Database devs are still part of the team and need to be included. So if we are going to include them what are some good practices to follow. I am sure, given some time, I could create a list of them. For now I just want to list a few important ones.

Start treating Database as Code

I am always encountering DBAs and Database devs writing scripts to deploy their changes to various environments. We need to get away from this practice. It is often error-prone and time consuming. The idea here is to put the database code into version control so that all changes are tracked. This allows us to be able to deploy in an automated and repeatable fashion to a Development environment and to run tests. Some benefits of this practice are:

  • This will allow the DBAs to focus on whats really important to them such as managing database changes.
  • Elimination of the deployment errors that can come from script writing and deployments
  • Takes the guess work out of knowing what database version is in what environment since an automation tool can track that

Single source of truth

One of the issues I run into quite often is that database devs store their version of the database code on file shares or cloud storage. This means that there may be many versions of the database out there and understanding what needs to be deployed is made that much harder. With Database as Code we can eliminate this practice and therefore have one source of truth for all database code. Treat the database files the same way you are treating your software code.

Team players

One of the tenets of Dev Ops is to be all inclusive in regards to development and operations teams. So why are the database developers left out? Makes no sense to exclude them. They are developers also. My suggestion is to get them involved in daily meetings your dev and ops team have. If you are using a Scrum or Agile approach, get them in the daily stand up. Not only will they feel more a part of the team, they can also make teams aware of hats going on in their world. Allow them to give updates and track there tasks in the same task tracking system that the development teams are using. If you use Kanban, get their tasks on the board and be sure to talk about their tasks. They need to be able to answer the same three questions that developers ask/answer

  • What did you work on yesterday?
  • What are you working on today?
  • Are there any impediments or issues the team needs to know about?

Like I said, this is not an all inclusive list , but is a great start to a database teams Dev Ops journey. I hope to see more and more companies adopting devops practices for the database teams.