What is DevOps?

The term “DevOps,” at the risk of traumatizing you with a bit of junior-high English, is a portmanteau of the words “development” and “operations.” The software developer and IT consultant Patrick Debois coined the phrase in 2009. It refers to combining the previously separate processes of software development (Dev) and IT operations (Ops), which was responsible for deploying software into production. DevOps is not a specific technology, nor is it a standard. Rather, it’s an idea—and an associated set of practices—that changes IT culture and the traditional methods of creating software.

DevOps came into being, in part, as agile methodologies accelerated the pace of software delivery. The traditional “waterfall” approach to software development had involved gathering requirements and realizing them through lengthy coding cycles. Coding a new version of an application might take six months or a year. When the developers were done, they would, as the saying goes, “throw it over the wall” to IT operations, who would go through their own laborious process of implementing it in the production environment.

The development and operations teams were almost always separate and managed by different people. They might even be in different organizational units. Tensions were constant, with finger-pointing and complaints about code not being ready for production, or operations people being overly strict about their requirements, and so forth. Operations might respond to new code by “throwing it back over the wall” for corrections. However, with agile development throwing code “over the wall” as often as multiple times a day, these tensions and operational frictions became untenable. Something had to give.

The solution was to merge the development and operations processes into a single workflow. The teams would also merge, to the greatest extent possible. This is DevOps, a situation where developers and operations people (as well as testing and QA) work in a collaborative, continuous process that pushes code into production as quickly and smoothly as possible. New, specialized tooling automates many of the steps. It’s not a utopia, but DevOps has indeed eased many of the old tensions and speeded up the process of getting high-quality code into production.

How does DevOps work?

DevOps comes to life through three interconnected elements: the DevOps team, the DevOps lifecycle, and the DevOps toolchain. The team is itself a major innovation, bringing together two groups that may have once had an adversarial relationship. The collaborative nature of DevOps succeeds, however, due to the process and toolchain. Using the toolchain, the team can execute the DevOps lifecycle. The practices of continuous integration and continuous delivery (CI/CD) are typically part of the DevOps process. With CI/CD, the DevOps teams integrate new code into the code base and deliver updated software to production on a continuous basis. 

Phases of the DevOps lifecycle

Stakeholders in DevOps like to represent the process using the metaphor of the infinite loop. The classic figure-eight design depicts an endless, iterative process that comprises the DevOps lifecycle. Although software development, testing, and releasing is a linear process, with DevOps, there is no particular starting or ending point. It’s always on, always iterating.

The ethos of DevOps is “collaborate and communicate,” which is the complete opposite of “throw it over the wall.” The resulting lifecycle puts these principles into action. The stages of the DevOps lifecycle are discover, plan, build (code), test, deploy, operate, and observe, followed by continuous feedback, which informs the discover stage—and the lifecycle begins anew:

• Discover: Exploring and prioritizing software ideas, seeking alignment with strategy and customer experience.
• Plan: Breaking work into small, manageable pieces that add incremental value.
• Build: Writing the code itself, with tools like Git enabling branching, merging, and rewriting the repository history.
• Test: Continuously running tests for software quality, often including the testing of application programming interfaces (APIs) that link the application with other software and data sources.
• Deploy: Continuously releasing new features into production using automation.
• Operate: Managing the complete delivery of the software to end users, deploying onto infrastructure—a process that includes design, configuration, and implementation of production environments.
• Observe: Identifying and resolving issues that affect the software’s performance and end-user experience—with automatic team notifications regarding issues.
• Continuous feedback: Evaluating each release and reporting on ways to improve future releases.

DevOps methods and practices

There are several different ways that DevOps teams can put the DevOps lifecycle into action. They are rooted in software development methodologies. For example, the Scrum approach to DevOps defines how team members should work together in “sprints” and related Scrum workflows. People on the DevOps team play certain Scrum roles, such as Scrum Master and product owner. With the Kanban approach to DevOps, team members track their work in progress (WIP) using the Japanese-style Kanban board.

DevOps vs DevSecOps

Some DevOps teams also incorporate various cybersecurity steps into the lifecycle. This is known as DevSecOps. Security steps might include things like testing for vulnerable code, API security testing, and adding data security countermeasures like encryption. DevSecOps is intended to produce secure software, while pure DevOps is all about efficiency and speed. The two goals are not necessarily in conflict, though security may create more steps in the lifecycle.

Efficient or not, DevSecOps or something like it is usually a necessity. Security problems are bad in general, but they are particularly troublesome for the developer team that has to fix them if a vulnerability gets out into production. Multiple studies have shown cost and time savings when addressing security issues prior to introduction into production. And, it’s quite inefficient and slow to have security be a standalone gating factor that occurs after the DevOps cycle is ready to release the code.

Benefits of DevOps

Done right, DevOps has proven itself to be a source of advantage for businesses and other entities that produce software. Speed is one of the biggest benefits of DevOps. By integrating teams and processes, the whole cycle gets faster. At the same time, collaboration and communication generally make the software better. There are fewer tradeoffs of “I can give you speed or quality, but not both.” With DevOps, you get both.

Team morale improves, too. This may not seem like such an important issue but given the difficulty that companies have recruiting and retaining developer talent, it’s a big plus. In addition to making people less stressed out, the collaborative nature of DevOps can identify opportunities to develop new features that no one thought of before.

Why DevOps matters

DevOps matters because it is a critical enabler of digital transformation. It is possible to undertake transformative technology projects without DevOps, but in reality, the speed and quality inherent in the DevOps model are essential for successful digital transformation. DevOps translates into faster delivery of business value through software.

DevOps has changed the software field for the better. It’s part of a bigger picture, one that includes agile methodologies, CI/CD, open APIs, and concepts like containers and microservices architecture. Not every organization is ready to embrace it right away, however. Getting to success with DevOps is an evolutionary process that requires change management. Indeed, it can be challenging. For some organizations, too, the waterfall technique is still viable, or even preferable, for certain software projects. For organizations ready and willing to adopt it, however, the potential for DevOps is clear.