This blog post is part of T-SQL Tuesday Blog series — thanks to Grant Fritchey (t | b)  – for hosting this month’s T-SQL Tuesday event.

“T-SQL TUESDAY #091 – DATABASES AND DEVOPS”

OK, so this DevOps thing – what is it?

I consider myself both a practitioner and preacher of the DevOps thing. It is one of my favourite things to talk about and also do. Done right it makes everyone’s lives a lot better. They say you should never discuss politics and religion and at times I feel like the ‘D’ word falls into this category.

It polarises people — people either love it, hate it or don’t know what it is (human instinct thus is to hate it).

At the company I work for – I had a saying “The first rule of DevOps is:  Never say the word ‘DevOps'”. It stopped the silly and juvenile arguments.

We focused on Continuous Integration and Continuous Delivery – which are components of the DevOPs movement.

So yeah DevOPs is not a thing, there is not a big ‘MAKE DEVOPS HAPPEN‘ button that you can push.

At it’s simplest it is about:

Tools, Process, People, Culture

The thing is you need to be aware of all 4 of these. If you concentrate on just one or maybe two – you’re going to fail at this ‘DevOPs’ thing.

So for this T-SQL Tuesday you’d think I would relish the chance to talk about all four things or at least Tools  – because database right?

Yeah, nah.

Only because we have Grant Fritchey hosting this event and the company he works for — Redgate do some fantastic game changing tools in this space. If you want to learn/do Database Lifecycle Managment (DLM) which brings DevOPs to the Database – go look at the Tools that Redgate have. Quite frankly they are game changers.

Now I love Tools, I’m a technical bloke and tools make a huge difference.

But…..you need process too.

In terms of Process – check out DLM Consultants  – Alex Yates (t | b)is a guy who gets how DevOps can really make database deployments not only easy but boring..

I’ve yet to meet Alex but he’s one of a few guys in this space (Steve Jones (t | b),  Damian Brady (t | b), Donovan Brown (t | b)) who I am looking forward to having a beer with and talking to blokes who really know their stuff around DevOps.

(Honestly — if you’re reading this far – STOP – look these guys up — they are awesome, knowledgeable and want to help you make stuff go)

OK…

Tools, Process are vitally important. But they aren’t the full story here. In fact to be honest they aren’t the most important parts of this equation:

Tools, Process, People, Culture.

Here’s another saying I have:

The Tools are great, but the Process is wrong, because the People don’t get the Culture.

DevOps is not easy to implement or adopt, and event harder in terms of transforming your company into an agile, business-delivery-focused machine. DevOps is not about having the best automation tools. It’s about people and process.

The thing that brings those two things together? To help break the old habits that are killing our ability to deploy changes more reliably and quicker to both application and database alike?

Culture.

The thing DBAs and OPs hate.

They love Tools, they’re OK with Process, People are kinda meh, but Culture.

Culture……. !!!!

Yeah, nah.

This post is about Culture. How culture can help your database.

“Now if you could just hold the hand of the person next to you while we sit in a circle and sing Kumbaya My Lord …..”

Just kidding.

The culture of DevOps is vitally important – in fact culture is the foundation of anything DevOps, Continuous Integration, and/or Continuous Delivery related.

For too long the Database – the MOST important part of any application – has been ignored in terms of applying DevOPs methodologies to it.

For too long application developers have enjoyed being able to release quickly, automatically and reliably to their applications, whilst our databases broke because of banked up changes, poor source control, manual processes and lack of communication between DEV and DBAs.

That last bit is the killer of all things — communication. Without communication we won’t have collaboration. Without collaboration we will have two or more groups of people who don’t understand what the others do/need and we won’t be able to achieve our goal.

The goal BTW is —  fast,reliable, repeatable and boring deployments of changes to PROD systems. Whether those systems are databases or applications.

Historically there has been a power struggle between DEV and OPS (DBAs):

• DEV want continuous change and fast enhancements, they are focused on meeting schedule targets.
• OPS want stability and rigorous/controlled change, they are focused on meeting reliability targets.
• To make it worse – both camps work in silos – with disparate tools and the only time they really communicate is when things go wrong…

See how this can go wrong…

The thing we need to change here is the Culture present in this situation. So that People can communicate, collaborate on the best Process that will use Tools. To achieve the goal.

If we look at another way of describing DevOps:

Culture — focus on people, embrace change and experimentation

Automation – Continuous Delivery, Infrastructure as Code (IaC)

Lean – Focus on producing value for the end-user, small batch sizes

Measurement – Measure everything, show the improvements to all

Sharing – Open information sharing, collaboration & communication

The CALMS approach is in fact wholly dependent on Culture.

As the culture will become one of sharing, one where we work together on the automation, one where we have a culture that embraces sharing/showing the metrics of our systems.

Our systems – this means we are ALL involved in the up-time, performance and changes associated with them.

So we need to embrace and implement a culture that is:

• Highly Communicative – by breaking down the silos we can communicate quicker
• People-centric – we want open minded people who have cross-pollination of skills
• Based on problem solving – we all work together towards a common goal(s)
• Focused on the End-User experience – the client pays us remember…!!
• Empowered and self-sufficient – DEV can spin up their own resources (IaC)

By the way – DevOps is not just about DEV and OPs (DBAs) – it is about a cultural philosophy for all members of our company that are involved in delivering business functionality to our end-user (clients).

This means the Functional Testers, Release Managers, Marketing, Sales Team, QA Engineers, Application DEV, Database DEV, Infrastructure Engineers, Report Writers, Operations Managers, DBAs, Business Analysts and even Consultants — all need to embrace the culture of DevOPs.

Because we are all involved in the goal. We all need to understand what the culture is and how we are a part of it.

How I sold DevOps to management at Jade Software was around reducing “Time in Lieu” as we had many people up at night or working on the weekend trying to get horrid manual deploys to work. Our  application deploys went from hours down to seconds and they were AUTOMATED. Our teams were at work the next day, instead of catching up sleep and instead of fixing things in PROD – they were learning how to do higher value activities. This is a good culture to have.

As I said before – for too long the Database side of the equation has been ignored in this process.  Databases are hard, if you do stuff wrong it is very, very bad. BUT if you start small, if you embrace the culture associated with automation, small changes, if you apply (flexible) standards and if you begin with PROD-like systems it is very achievable. You can realise the benefits of DevOps with your databases.

Lastly — please….

Regardless of whether you are a DEV or a DBA consider Test Driven Development (TDD) for any code you write. Rob Farley (t | b) writes a good post related to how it fits into “Databases and DevOps” realm here.

There is a revolution happening and the associated blog posts that are associated with this month’s T-SQL Tuesday event will hopefully show you why it is a great thing applying DevOps principles to your database.

Yip.