The Art of Agile Development, 2nd Edition

CHAPTER FIFTEEN

DevOps

When I first started programming, my job was clear: build software and hand it off for release. After the handoff, a mysterious process would get the software into the hands of customers. First, it involved shipping CDs; later, it involved a distant department, called “Operations,” that seemed obsessed with bird calls. (awk! grep! perl!) Either way, it was no concern of mine.

This continued even after I started practicing Agile. Although Agile teams are meant to be cross-functional, operations were handled by other people—people I never met and rarely even knew the names of. I knew this wasn’t in the spirit of Agile, but the companies I worked with had strong walls between development and operations. Secretly, I was glad.

Fortunately, others in the Agile community weren’t so complacent. They worked to break down the walls between development and operations, and later, the walls separating security as well. The movement came to be known as DevOps. It’s also called DevSecOps.

NOTE

As with so many things in the Agile ecosystem, the term “DevOps” has been distorted by well-meaning people making incorrect assumptions…and less well-meaning companies trying to make a quick buck. Here, I’m using it in the original sense of the word: close collaboration between development, operations, and security.

Some people extend DevOps to even more domains, with terms such as DevSecBizOps, DevSecBizDataOps, or even Dev<Everything>Ops. Of course, that brings us full circle to ...