Agile development methodologies have broken down the silos between requirements analysis, software development and testing. The result is greater collaboration among software developers and product owners. But deployment, operations and maintenance – the people who make sure software gets into production -- have retained separation from that process.  That’s where DevOps – the confluence of software development and software operations – comes into play. The idea behind putting the two more closely together is to remove the remaining silos and drive collaboration to achieve continuous improvement and delivery of software to organizations.

“The concept of DevOps is simple. But the things an organization must do to implement the continuous improvement/continuous delivery model are more complex,” said Kevin Rhoades, TDK Director of Project Solutions.

Problems often arise in traditional environments that include a disconnect between those who develop software and those who put the software into productive use. Conflict and inefficiency results.  The developer arena is agile and open to change, but is not always consistent in delivering software. The operations side on the other hand prefers consistency and views change as inefficient.

“Developers live on the ‘bleeding edge’ of everything. We want our machines updated to the highest possible degree. Yet production machines are often anywhere from 18 months to five years behind on updates. So, there is a disconnect there that must be acknowledged,” said Mark Henman, TDK Chief Technology Officer. “DevOps is a way to try to get teams to work together toward a common goal and to provide the tools to support that.”

A typical problem is where the development team is using one tool to track tasks and another tool to track ‘bugs’, while the operations/maintenance staff is tracking issues in yet another tool. In this case, there are three tools being used for the same software application. The mindset of a DevOps engineer is to get everyone on the same system to manage the life cycle of the software delivery.

“Where we can add value as a software development team is by helping clients from a people, process and tools standpoint simplify their lives. We can help clients make the flow of the software delivery happen more quickly, in a more automated fashion and more effectively,” Rhoades said.

“What is bridging the gap for DevOps is the reality that nearly everything in our infrastructures is software-defined; server configurations, network layers, telephony systems and the like. What we have now in source-control is not just the application code. But it’s the database constructs, machine configuration definitions; really everything that’s required to build the entire environment,” Henman said. “What it means is that when everything is driven by configuration, the source-control system provides a way to implement changes across the environment and support operations at the same time.”

How Can Dev and Ops Work Together?

Continuous integration and continuous delivery of quality software depends on a system where deliverables can be packaged and automated as much as possible. That facilitates a more integrated process.

“DevOps is not something you tack on at the end of a project,” Henman said. “It’s not where we’ve taken development tools or methods and imposed them on the operations team. It goes both ways. We’ve taken operations elements and brought them forward to the very beginning of the development effort.”

A resource with considerable detail on the topic is Joakim Verona’s book Practical DevOps, which looks at the process conceptually as a continuous delivery pipeline.

  • Developers create code from workstations and require many tools to be efficient. The ideal situation is to have a production-like environment locally on their workstations. However, it is more common to simulate parts of the production environment, so software can be deployed in a production-like way.
    • In the early stages of a DevOps project, developers can work together with the operations team to build a container-based or virtualization-based development environment that is set-up according to operations standards.
  • The Revision Control System is called ‘the heart of the development environment’ in Verona’s book, where modifications to the software being developed are continuously deployed using build servers with results of the changes compiled in an artifact repository. This is where the organization’s code, infrastructure configurations and perhaps designs for hardware development are located.  
  • Test Environments are next in the DevOps pipeline. This is where verified code is installed and configured with the same methods used in production, for integration testing and performance testing.
    • The last line of test environments is staging, which is interchangeable in nature with production environments.
    • When new releases are installed on staging servers, and pass final testing, the old production servers are swapped out. So, the staging servers become the new production servers. This has been called a blue-green deployment strategy.
  • Release management is almost fully automated in the DevOps ‘dream scenario’, but is challenging to achieve in real applications. It is difficult to get to the level of test automation needed to produce confidence in reaching automatic deployments.

“That is the goal. But it is unlikely software will be deployed automatically. There will always be a human who ‘owns’ that,” Rhoades said. “Having said that, automation makes DevOps possible. It helps create confidence in the development process, integration and testing to the point where you can trust it so implicitly that someone could literally ‘flip a switch’ and implement the new release.”

The DevOps Culture

DevOps seeks to maximize technical aspects across the disciplines involved in software development. But it also affects the non-technical cultural aspects of organizations as well. Successful implementation of the continuous integration/continuous deployment (CICD) model requires a commitment throughout the organization -- starting from the top -- that involves time, resources and training.  At the heart of successful DevOps organizations, you will find shared responsibility, increased collaboration and a willingness to change.

“DevOps is more of a culture than a set of tools. It’s a mindset that nothing is sacred, that everything can change. But it must occur in a systematic, methodical way that accepts change, predicts change, wants change and grows with change. It is putting in place a complete pipeline for continuous integration and continuous delivery. That differs greatly from the finger-pointing mentality that previously may have existed,” Henman said.

Successful DevOps organizations include autonomous teams, a concept driven by the agile mindset, that work across functions and have tools to transparently access everything that is changing in the work flow.  Automation is key for as many processes as possible; source-control, builds, code testing, configuration testing, deployment, system metrics and more.

“The goal of DevOps is not to make all developers into operations specialists. It’s not to make operations specialists into developers,” Henman said. “It’s to make each of them aware of the other’s tasks and duties so they can help each other, rather than be a hindrance to each other.”

DevOps seeks to create a way where continuous integration and continuous delivery can take place quickly. But despite the automation that is fundamental to DevOps projects, communication will remain a key to success.

“To me, 90 percent of execution is communication. And strategy is 90 percent execution,” Rhoades said. “Just because automation is involved, teams working in a DevOps environment still must communicate well. One of the challenges will be to keep the communication in line with the pace of activity, which increases considerably in the DevOps scenario”

“The first time a company tries to embrace DevOps, they will find it takes a significant time commitment to build that pipeline, to get all the tools up and running, to determine where the gates need to be, who is responsible for it, and so forth. But once it’s there, follow-on projects accelerate tremendously,” Henman said.

An IT pro who'll take the time to learn my business. Is that too much to ask?