One of the main reasons I joined Redgate as an Evangelist is that I believe DevOps has a lot to offer to database administrators, developers, and company leaders. DevOps not only increases productivity, but improves company culture and makes work more fun.
In speaking with DBAs, devs, and company leaders in customer calls, at conferences, and in online forums, I’ve found that there are three key points about DevOps which are far from obvious.
1. 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. This is not only the costs for tools, but also the operational cost of 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, creating and optimizing automation pipelines, 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.
This study 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.
2. 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 SEEK DevOps team took over the build, deployment, and operational support for the organization’s critical websites. Here’s what happened:
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 outside of the “DevOps team” and into developer and IT teams, these teams became autonomous units who could support their own releases. This is the path to both higher quality and higher release frequency.
3. 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
Want to learn more on this topic?
Next week, I’m giving a free webcast for Redgate in which I’ll discuss these topics and much more. I’d love to hear your questions, comments, and stories about DevOps during the event.
The webcast will be held on Wednesday, Jan 23 at 8 am Pacific / 11 am Eastern.
