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.

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 cross-functional, autonomous teams who have all the skills they need to be successful. Or, you know...Agile.

By breaking down the walls between development, operations, and security, DevOps allows your team to create software that’s safer, more reliable, and easier to manage in production. This chapter has four practices to help you do so:

• The “Build for Operation” practice creates software that’s secure and easy to manage in production.

• The “Feature Flags” practice allows your team to deploy software that’s incomplete.

• The “Continuous Deployment” practice reduces the risk and cost of production deployment.

• The “Evolutionary System Architecture” practice keeps your system simple, maintainable, and flexible.

DevOps Sources

The term “DevOps” was popularized by Patrick Dubois, who hosted the first DevOpsDays conference in 2009. The idea of breaking down barriers between devs and ops predates the term, without any clear source, but one of the earliest examples is Benjamin Treynor Sloss’s creation of Site Reliability Engineering at Google in 2003. In [Beyer2016], he writes, “One could view DevOps as a generalization of several core SRE principles...[or] equivalently view SRE as a specific implementation of DevOps with some idiosyncratic extensions.” This core idea of working together is captured in Build for Operation.

Feature Flags are also known as feature toggles. Like DevOps, they’re a fairly natural expansion of Agile ideas—in this case, continuous integration—with no clear source.

Continuous Deployment is also a natural expansion of continuous integration. Kent Beck included a similar practice, “Daily Deployment,” in the second edition of XP. [Beck2004] The first use of the term I’m aware of is in Paul Duvall’s book, Continuous Integration. [Duvall2006]

Evolutionary System Architecture is an application of XP’s evolutionary design ideas to system architecture.