Praxis (noun): practical application of a theory.

This page enumerates DevOps ideas from literature and from community conversations, including citations, and pairs them with how, if at all, to implement these ideas in-real-life. It includes my personal attempt to wrestle with the sometimes contradictory ideas.

Note: this post, like all of my posts, is a work-in-progress.

In recent days, circa May 2021, I've come to see "DevOps" as a Janus word (like sanction, agile, or clip), which means the opposite of itself depending on the context. In the sales-y context, it seems to mean vendor-specific tooling for operations. In the revolutionary-idea context, it seems to mean a cultural attitude and a set of best practices for actualizing that attitude.

In my struggle to understand, I have also found that talking about DevOps is sensitive territory. It's a bit like talking about religion, or politics, or morality. In other words, generally, we do not talk about these topics in polite society, especially if we want a repeat invite! The irony is that, because these topics are important, talking freely about them can be inappropriate, because humans are emotional creatures. We can blog about these ideas, though. To whit, here we go...

Principles and Practices

Four Kinds of Work (Kim et al, 2018)

Business Projects
Internal Projects
Operational Change
Unplanned Work

Four Key Measures (Forsgren et al, 2018)

Lead Time
Deployment Frequency
Mean Time to Restore (MTTR)
Change Fail Percentage

Westrum Typology of Organizational Culture (Forsgren et al, 2018)

Pathological / Power-Oriented
Bureaucratic / Rule-Oriented
Generative / Performance-Oriented

Continuous Delivery (Forsgren et al, 2018)

Version Control
Deployment Automation
Continuous Integration
Trunk-based Development
Test Automation
Test Data Management
Shift Left of Security
Loosely Coupled Architecture
Empowered Teams
Monitoring
Proactive Notification

Lean Management (Forsgren et al, 2018)

Limit Work in Process (WIP)
Visual Management
Feedback from Production
Lightweight Change Approval Process (CAP)

Lean Product Development (Forsgren et al, 2018)

Work in Small Batches
Make Flow of Work Visible
Gather & Implement Customer Feedback
Team Experimentation

Transformational Leadership (Forsgren et al, 2018)

Vision
Inspirational Communication
Intellectual Stimulation
Supportive Leadership
Personal Recognition

Questions with and without Answers

Should my user be part of the DevOps group/role in our authorization system?

We have a job description for a DevOps Engineer. What does that mean?

Is task <some-task-here> a job for the DevOps department?

DevOps Departments

Ah, DevOps departments...

DevOps departments are a thing, but my concern is that, despite it being a common practice, I do not understanding the spirit of that practice, and I am skeptical about the usefulness of such a department. I am looking for existing literature, from the wider software development community, that is in support of building a DevOps Department.

As early as 2014, Puppet Labs raised the problem.

Despite a growing trend of DevOps departments, we think a dedicated team can miss the point. (Puppet Labs, 2014).

So what is the point that we’re missing? Even earlier in the history of DevOps, in 2012, one of its early advocates Tweeted in a fit of rage.

In a fit of rage caused by reading yet another email in which one of our customers proposed creating a “devops team” so as to “implement” devops, I tweeted that “THERE IS NO SUCH THING AS A DEVOPS TEAM.” Like all slogans, there’s plenty of heat to go with the light, so here’s the scoop: the Devops movement addresses the dysfunction that results from organizations composed of functional silos. Thus, creating another functional silo that sits between dev and ops is clearly a poor (and ironic) way to try and solve these problems. (Humble, 2012)

So my question is, what is a DevOps department? Does it sit between development and operations? Is it a euphemism for operations? What does it mean to be hiring for a DevOps engineer? What is the cultural impact of having a DevOps group in active directory? Is this another functional silo? Are these uses of the term clarifying the situation or making it murkier? Does language matter? Are we helping our DevOps culture or hurting it, unintentionally? And most importantly for me, what resources can I read that recommend and explain what a DevOps department/engineer does and how that aids overall IT performance?

In more recent reports by Puppet Labs (2020), there is talk about “Internal Platform Teams.” Is that what we’re going for here? If so, does calling that a DevOps team increase or decrease the clarity of our internal and external communication? My sense is that there might be a more canonical term, from the literature on DevOps, for what we are trying to achieve - maybe that is an Internal Platform Team.

In the same essay, Humble (2012) emphasizes that he is arguing, “against creating a devops team – in addition to the existing dev and ops teams – whose job is to be on the hook for the deployment of the system.” He also says that sure, we could call a DevOps team one that supports developers to do these four things:

…build reliable software that can be continuous deployed
…self-service environments and deployments
…write testable, maintainable code
…do packaging, deployment, and post-deployment support

The idea is that each developer will maintain responsibility for each of those four tasks, and the “DevOps Team” will support that. He ends by saying, with perhaps a does of sarcasm, “Really this is all part of the work of operations. But if you want to call the people who do it your “devops team” then that’s cool too.” Okay, so maybe we are upsetting a language purist. Does our use of language matter?

I know that “DevOps Specialist” and “DevOps Engineer” are in common use in job postings. What I don’t know is what those terms mean to to the wider software developer community, and to the effectiveness of internal and external communication. I am longing to read some industry literature about those positions, what they do, and how they help our performance.

It was lovely to see this question, "Is DevOps a job title?", answered directly by Microsoft (2021). This is their answer:

DevOps is not limited to a single role. Everyone who takes part in each of the application lifecycle phases must embrace the DevOps culture. However, in some organizations there are a few people or teams whose sole focus is enabling automation, defining practices, and implementing CI/CD pipelines. Sometimes, the official title of these roles is DevOps engineer or DevOps specialist. [emphasis added]

Resources - Some Cited in the Text

Books

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. Place of publication not identified: IT Revolution Press.

Kim, G., Behr, K., Spafford, G., & IT Revolution (Portland). (2018). The phoenix project: A novel about IT, DevOps, and helping your business win. Portland: IT Revolution.