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.
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:
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
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.