September 16, 2019

Doing DevOps in 2019

I recently had the pleasure of presenting a webinar with Dr. Nicole Forsgren. For the uninitiated, Dr. Forsgren is a leading IT impacts expert best known for her work with tech professionals and as the lead investigator on the largest DevOps studies to date. Recently, she and her team at Google Cloud released the 2019 State of DevOps Report.

Our webinar covered some of her findings (there was a lot to unpack) and the role of the database in all of this DevOps stuff.

One of the best things about Dr. Forsgren is her ability to break down what’s going on in software development in very easy to understand and accessible terms. Here’s a bit about what we learned during our time with her this week.

What is DevOps in 2019?

“Developing and delivering software with speed and stability so that we can deliver value to end users and customers.” – Dr. Nicole Forsgren

According to many analysts, DevOps has crossed the chasm. Companies are realizing fantastic results. The most exciting part is that anyone can do it. It takes work and requires execution on four key metrics to track technology transformations because they impact Availability (the promises made to end users and customers):

Speed Metrics

Lead Time
How long does it take to get from code check-in to code in production?
Frequency
How often do I deploy code?

Stability Metrics

Change Fail Rate (% of changes that fail)
Does the code cause an incident or require human attention?
Time to Restore
How long does it take to get back up if there is a problem?

The DevOps Elite/High Performer Backslide

For each of the four key metrics tracked, the report breaks companies down into four categories: Elite, High, Medium, and Low performers. One of the most interesting findings in this year’s report is that from 2018 to 2019, some of the elite and high performers backslid. The reason? They thought that they were done. “We already did DevOps!” These companies achieved level 5 on their maturity model and they stopped investing in getting better. Their technological complexity fell on them and they stopped.

Being an Elite DevOps Performer

DevOps is like being a marathon runner. Just because you’ve run a marathon before doesn’t mean that you can run one next year without training. To extend the metaphor further, if you want performance outcomes it requires good shoes (automation and technology), changes in habit (optimizing processes), and friends/accountability (culture investments).

Low DevOps Performers

Okay, so not everyone can be (or perhaps even wants to be) an elite marathon runner. But even if you’re not striving to be the best of the best, the numbers in the report make it clear that it’s important to at least get to a 10k.

That’s because when organizations deploy infrequently, the changes batch up. When teams finally do push to prod, it’s large. This means a higher likelihood of failure that’s difficult to correct and debug. Based on the results of the report, slower deployments bring more instability. The problem compounds.

DevOps is About Getting Better

DevOps is more than deploying and delivering features faster.
It’s keeping up with regulatory changes, security incidents, changes in infrastructure, keeping up with the database, and everything else.

“DevOps is improving everything that touches your code and everything your code touches.” – Dr. Nicole Forsgren

How Do You Get Better at DevOps?

First, you need to identify your goal. This year’s report is designed to help drive improvement in both performance and productivity using two research models:

Software delivery and operational (SDO) performance
Productivity

The report walks you through both adventures, but we’re going to concentrate on how database change and release automation can help organizations get better at DevOps.

Get Better with Database DevOps

It doesn’t matter if you are a low, medium, high, or elite performer — integrating database change and release automation into software delivery positively contributes to SDO.

All code matters! Don’t forget the database code.

Do you need a shared data services team to get insight into the database code? If someone changes a stored procedure and adds a parameter, does it break everything because they didn’t know what else was dependent on that code? It’s time to consider database code in the same way that you think about application code.

Code Maintainability

According to the data, code maintainability contributes to Continuous Delivery and helps reduce technical debt. Focusing on code maintainability means enabling others. Just like software developers need to make it easy to use others’ code so you can migrate to new versions without breaking dependencies, it’s equally important that they also make it easy to use and access the database without breaking it. Stop directly accessing the database with code and start using shared web services for database access.

Improving Productivity

Productivity is not story points.

“Productivity is the ability to get complex, time-consuming tasks completed with minimal directions and interruptions. This kind of productivity helps us leave work at work and reduce burnout. ” – Dr. Nicole Forsgren

Database Schema Change Process
Today, the database is the poster child for “heavyweight change approval process”.

Manual reviews, ticketing, and other heavyweight process and controls negatively impact SDO performance. In contrast, having a clearly understood process for changes drives speed and stability, as well as reductions in burnout.

Myth: Formal change approval processes lead to more stability
Fact: There’s zero evidence that supports this.

Myth: Having more approval processes in place fixes software release problems.
Fact: Simply doing a better job of communicating the existing process and helping teams navigate it efficiently has a positive impact on software delivery performance.

Leaders at every level should move away from a formal review process with gatekeepers approving changes. In order to be more productive and efficient, move to a governance and capability development role.

“I’m seeing reduced technical debt all over this slide.” – Dr. Nicole Forsgren

Summing it up

There’s a path for getting better at DevOps. Choose your adventure based on what your goals are and keep working on it. DevOps isn’t a destination. You’re never done. Remember the database! A lot of organizations have thrown a lot of people and resources at this problem for so long that they’re blind to it. Start looking into automating database change and release to free your team from technical debt, improve their productivity, and reduce burnout.

Check out the full webinar recording for 2019 State of DevOps Report: Database Best Practices for Strong DevOps.

Download the full 2019 State of DevOps Report.