Your data is at risk …….

 

Guest Post by Hamish Watson (B|T).

This post is a guest post at SQL Masters Consulting. I chose to write about why people need to embrace DevOPs for their database and yes I admit — the title is clickbait.

SQL Masters Consulting is a company that has been built around performance tuning and understanding the needs of your data. It is encouraging to see companies like SQL Masters Consulting now looking at how DevOPs principles and the resultant efficiencies can be applied to databases. This is truly a game changer in the industry and being able to help clients realise the benefits of DevOPs for the Database is a valuable thing.

Your data is your most vital asset, it is the most long-lived thing you will have in your company, it will outlive the COBOL compiled applications, the .NET frontend and the python scripts that interact with it. Thus you need to look after your data wisely and carefully.

You should not put your data at risk and that is where the second part of the title comes into play.

FearOps :: I heard about FearOps in 2015 when Terri Haber (T) wrote about it when she worked at Puppet, it struck a chord with me as it described accurately what a lot of people are experiencing with getting changes deployed through to PROD systems.

Those changes were typically manually deployed, they involved developers who “wrote bad code” and DBAs whose main word of choice was “no”.

There was mistrust between the 2 teams, changes were done manually because no one had any trust to automate things and thus things were done inconsistently. Testing was at best done inconsistently (manually) and at worst – what testing?

So when it came to deploying code to applications or the database there was the following scenario:

A room full of people, sweating, huddled around computers, there might be pizza and its 3am and if anything goes wrong with this deploy heads are going to roll…

To make it worse they’re going to deploy 3 months’ worth of changes – in one go.

Fear….

When you are operating under FearOps you do not trust anyone or anything. Because the problem is that we humans are fairly inconsistent creatures, ergo we make mistakes.

To make things worse – developers are rewarded on the amount of change they can create, whereas operations (DBAs) are rewarded for stability and uptime – thus they don’t want any change and are seen as gatekeepers.

If you are not testing the code that is interacting with your database – be it that new shiny application or a newly written stored procedure then your data is at risk.

If you are doing code changes directly into PROD at the last minute without any form of testing beforehand then your data is at risk.

If you are not storing your database changes in source control and utilising Continuous Integrations then your data is at risk.

Deploying to databases is not easy, in fact it is downright hard and the consequence of failure in PROD is enormous – which is even more reason why it is fundamental to look at things like DevOPs principles for the database.

Basically if you are not embracing the principles of DevOPs – namely Continuous Integration and Continuous Delivery then you will experience FearOps.

Your data is at risk.

There is good news – for years application developers have learnt the benefits of unit testing, source control, integration testing all leading up to repeatable, reliable and automated deploys to PROD systems that don’t break things. That allow the safe delivery of business value to customers.

In the recent 2017 State of Database DevOps survey it was found that Continuous Integration was in place for 39% of applications but fell to 20% for databases.

It is now time for database developers and DBAs to embrace these same techniques/philosophies.

It is now time to utilise the maturity of the Azure platform to host your systems cheaply and efficiently, to use Infrastructure as Code to automate the rollout of resources, to investigate how containerisation can help with standardising the application and database runtimes and why gitflow is one of the best things you can learn for improving the stability/quality of your code.

For too long we have had 2 separate deployment conversations about applications and databases – we need to start treating them both the same so that our data is not at risk.