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.