Blog Post

3 Key Points from My Upcoming Talk, “DevOps: What, Who, Why, and How?”


Next week, I’m giving a free webcast for Redgate on DevOps fundamentals. DevOps is something I am a big proponent of for database administrators, developers, and company leaders. The webcast will be held on Wednesday, Jan 23 at 8 am Pacific / 11 am Eastern.

Click here to register and get a reminder to attend the live webcast, or to watch the recording after it airs.

I’ll share a lot of information in the talk. As a preview, here are three points which are often the source of misunderstandings:

Developer productivity is a top concern of C-level executives

Implementing DevOps isn’t something you do in an afternoon. Often, DevOps implementations begin from the C-suite as part of a digital transformation effort. DevOps can also be originated from small teams in the company who transform their own practices, share their success with the company, and enlist executive support to spread these practices to other teams.

Many DBAs and developers worry about the costs of implementing DevOps: not only the costs for tools, but also slow-downs in delivering new features while working on important projects that are the foundation of DevOps, such as standardizing the database code in Version Control and writing tests.

We should all be less worried about opening this conversation with company leaders, however. In September, 2018, Stripe performed a study with Harris Poll on software engineering efficiency. They got the following response from more than 1,000 C-level executives:

96% of C-Level execs polled believe that increasing productivity of developers is a high or medium priority

Slowdowns in productivity can be painful. But if they result in increasing the overall productivity of developers afterward, that slowdown pays off quickly.

The study overall found that a “lack” of developers is not the main problem: instead the problem is leveraging existing talent within companies better. DevOps directly addresses this problem.

Having a team who does DevOps “for you” doesn’t work

It’s common for companies seeking to release code changes faster to implement a “DevOps team.” While specialists can help larger teams adapt DevOps practices, inspire DevOps culture, and suggest patterns for work that get the cycle of continuous improvement started, these teams can’t do DevOps “for” other teams.

Andrew Hatch, Platform Engineering Manager at SEEK, has written about why SEEK created a DevOps team, what happened with the team, and why they ultimately decided they no longer need a DevOps Team.

In his article, Andrew Shared that the DevOps team took over the build, deployment, and operational support for the organization’s critical websites, but:

We had made rapid advances in our delivery processes but we still faced torrid nights on-call with software systems straining under the sheer volume of product being deployed to them.”

Why We Don’t Need a DevOps Team by Andrew Hatch

Doing DevOps is not only about release tempo. Other measures regarding stability are hugely important:

  • Time to restore service
  • Rate of failure of changes

By spreading the DevOps culture into developer and IT teams and making them autonomous units who could support their own releases, the team at SEEK were able to improve quality and maintain their higher release frequency.

Doing well at DevOps means including the database

Dr. Nicole Forsgren of DevOps Research and Assessment (now part of Google) is an internationally known researcher into DevOps practices. In the 2018 State of DevOps Report by DORA, they found that…

Teams that do well at continuous delivery store database changes as scripts in version control and manage these changes in the same way as production application changes.

2018 State of DevOps Report, DORA, Dr. Nicole Forsgren, Jez Humble, Gene Kim

Making this work well doesn’t mean getting rid of database specialists. Instead, DBAs are part of the DevOps culture:

Furthermore, when changes to the application require database changes, these teams discuss them with the people responsible for the production database and ensure the engineering team has visibility into the progress of pending database changes. When teams follow these practices, database changes don’t slow them down, or cause problems when they perform code deployments.

(Emphasis mine) 2018 State of DevOps Report, DORA, Dr. Nicole Forsgren, Jez Humble, Gene Kim

I have lots more to share!

In my upcoming webcast, we’ll talk more about what DevOps is, who is involved in DevOps, and the impact DevOps has on organizations.

Register here to join me in next week’s webcast.

Original post (opens in new tab)
View comments in original post (opens in new tab)


You rated this post out of 5. Change rating




You rated this post out of 5. Change rating