DevOps Reference Architectures: What about the Database?

DevOps best practices abound. In fact, our friends at Sonatype have collected 73 DevOps reference architectures. Wow! That’s a lot of architecture!

There are three that we like here at Datical. The ones from IBM, CA, and AgileTrick have completion and clarity as their strength. Each has the following components: Source Code Management, Build/Continuous Integration, Asset Repository, and Release Automation.

The purpose of a reference architecture is to detail the system components you need for success. None of the 73 DevOps reference architectures make distinctions for programming languages or system architectures. Whether you are building a three-tier Java Application on-premise or a Mircoservice Node.js Cloud Application, it makes no difference: you need these components to adopt DevOps.

It follows that all components of your DevOps implementation should include the Database. At that point, implementers begin to have confusion on how to apply DevOps to the Database. The answer is simple: the same way you’ve done it for the other parts of your Application Stack. If you do it for the compiled bits, you need to do it for the Database.

For example, for SCM (source code repository), you should have all Database changes, just like all Application changes, in the SCM. Some companies will be tempted to have separate repositories for the Database and the Application. Don’t. You might be tempted to use a product vendor’s proprietary, internal SCM for the Database. Don’t. The reason why you have SCM is to track every single change that happens to your entire Application code base. The Database should be part of this.

The simple benefit of aligning Database and Application changes in SCM is that when you branch, you get a branch of the entire Application, not just a piece. When you tag the SCM for a build, the entire Application is tagged, including the Database changes. You decrease the overhead for Development AND Operations. Previously, I have had to answer the question, “What version of the Application goes with which version of the Database?” You can eliminate that overhead immediately by using your existing SCM for the Database.

Another component of DevOps Reference Architectures is Build/Continuous Integration. There are many reasons to automate Builds, but the major one is that if Continuous Integration is good, then you should do it all the time. Different teams often work on different parts of the application. Those teams need to know immediately if their changes have harmed another application component. This is especially needed as we shift to Microservice architectures. The same can be applied to the Database. If one team changes a Stored Procedure that another team uses, CI can help the other team by quickly identifying the problem just like a Unit Test.

Secondly, the Build/Continuous Integration server creates an artifact, a releasable immutable thing. You need the same for your Database changes. Immutable means “unable to change”. So, when you deploy Release 2.23 in ANY environment, it’s the same thing. You don’t have the ability to change Application Code in the Release 2.23 artifact and shouldn’t be able to do so for your Database changes. Your Build/CI server should be able to capture Database changes from your SCM and create an immutable artifact for your ENTIRE Application stack.

Of course, you will need to place that release artifact somewhere safe. That’s where Asset Repositories come in. Your Database changes, as part of the release artifact, will reside in the Asset Repository and be available for the next step, Release Automation. The Asset Repository will secure your artifacts and track all versions and changes.

Finally, Release Automation is the last mile of DevOps and the most visible part of it. There are many great Application Release Automation (ARA) solutions available. When we speak of ARA, it’s important to note that “Application” is capitalized. You need to include the entire Application in ARA, not just the easy compiled bits. The Database is crucial to your Applications’ functionality; it won’t work without the Database. Thus, if you do not include the Database in ARA, you will see wasted effort as your ARA is not true automation, it’s manumation.

To see how applying a DevOps reference architecture that included the database can lead to DevOps Success watch this: NBCUniversal & Datical: Achieving DevOps Automation for the Database.