DevOps is more than continuous integration and delivery

Comments 0

Share to social media

I recently presented a session about DevOps for DBAs, explaining what it is and why DBAs should care. One of the comments I received was “I thought I knew what DevOps was. Thanks to your session, now I know better.”

Here’s one definition of DevOps:

The union of people, process, and products to enable continuous delivery of value to our end users –Donovan Brown, Partner Program Manager, Azure Incubations at Microsoft

Notice that the definition doesn’t say you must use any particular toolset or prescribed methodology. The “people” are equally as important as the “processes” and “products” (tools).

You have probably heard (or said yourself) “It worked on my machine!” In a DevOps organization, everyone must be accountable for the end result – delivering customer value – not just responsibility in their domain. DBAs who are traditionally rewarded for keeping systems stable must embrace change. Developers who are traditionally rewarded for delivering functionality quickly must make sure that the changes can be safely deployed. Both sides share responsibility for stability and release tempo and must keep the end goal in mind.

DevOps is more than automating builds and deployments. DevOps requires that barriers between departments and teams are broken down. Communication, collaboration, and trust are paramount. As professionals, we often like to work independently or within our own teams even hoarding knowledge, but these silos can be broken down and replaced with cross-functional teams. DBAs can be embedded in dev teams, for example, and both sides benefit by sharing domain knowledge, information, and ideas.

DevOps is a mind shift within a company and can affect all aspects of the business. While automating infrastructure, builds, and testing is essential, DevOps means more. For example, when something goes wrong, understand the failure and learn from it; don’t assign blame. DevOps means continuously learning and continuously improving from the C-level down.

An organization can adopt DevOps because of a proclamation from management, but it can also happen via a grassroots effort. If DevOps practices are successful for a small project, word can get around, and it can eventually spread across the organization. I found the book The Phoenix Project by Gene Kim, Kevin Behr and George Spafford helpful for understanding how a company can embrace DevOps. It’s a fun fiction novel that shows how communication, trust, and cooperation are critical for DevOps.

DevOps is as much about culture and cooperation as it is about automating deployments.


Commentary Competition

Enjoyed the topic? Have a relevant anecdote? Disagree with the author? Leave your two cents on this post in the comments below, and our favourite response will win a $50 Amazon gift card. The competition closes two weeks from the date of publication, and the winner will be announced in the next Simple Talk newsletter.


Load comments

About the author

Kathi Kellenberger

See Profile

Kathi Kellenberger is a Customer Success Engineer at Redgate and a former Microsoft Data Platform MVP. She has worked with SQL Server for over 20 years and has authored, co-authored, or tech edited more than 20 technical books. Kathi is a volunteer at LaunchCode, the St. Louis based organization providing free training and paid apprenticeships in technology. When Kathi isn’t working she enjoys spending time with family and friends, cycling, singing, and climbing the stairs of tall buildings. Be sure to check out her courses on Pluralsight.