Why DevOps Needs Release Management

1. Fragmented Information, Informal Collaboration

DevOps prioritizes the creation of small teams and giving them wide latitude to create and deploy applications. This process helps speed up the application development and deployment process but creates and perpetuates the myth of entirely self-sufficient teams. In reality, both the teams and the software they are creating have complex dependencies. The DevOps process tends to create information silos, making each team a black box. In the absence of a formal system to organize cross-team and cross-departmental collaboration, everything from information sharing to collaboration is done in an ad-hoc, informal, and fragmented way. 

“The vast majority of the project programs focused around business capabilities have dependencies in and out, upstream-downstream, but a good portion of them think they live in their world,” explains the Director of Release Management at a global pharmaceutical company. Often, individual teams are too low-level and focused on specific functionality—authentication management, for example—to see the bigger picture or even how authentication management fits into and depends on other parts of the application. DevOps gives the illusion of independence, but when one team changes or deletes a resource another team’s app depends on, the consequences can be dramatic. 

In addition, it’s difficult for anybody to get a complete view of an organization’s suite of applications. “Information is often fragmented, informal and not capable of delivering true decision-making information to key stakeholders,” Plutora CEO Dalibor Siroky explains. Businesses create software to meet business objectives, but the lack of visibility into the organization’s software pipeline makes it difficult to make informed business decisions. 

2. Constant Change

“Everything is shifting all the time,” explains the Director of Release Management. “People change, the roles change, there’s a lot of shifts in and out of responsibility.” This state of constant flux makes it difficult to get everyone in an organization on the same page. Everyone has different cycle times and different responsibilities in the application lifecycle. In addition, each team might follow a different development and deployment procedure, use different tools, and write applications in a different language. 

Constant change means that information has to be available in real-time because it can be out of date immediately. But relying on the informal, point-to-point information gathering common in the real world makes it impossible to get an accurate view of the changing application landscape. 

3. Decentralized Accountability

In the past, there was more of a centralized gatekeeper that all new code had to go through. DevOps breaks down this centralized role, creating more acceptable pathways to get into production. Cross-functional, product-oriented teams that include experts in development, testing, security, and deployment have the autonomy to deliver their code directly—as well as the responsibility to run the application once it deploys. There’s no centralized oversight at any part of the application lifecycle. This autonomy is a key part of DevOps, but in an environment where information is often siloed, dependencies are poorly understood, teams are delivering as fast as possible and everything is in constant flux, the decentralized responsibility for releases is a recipe for disaster. 

“Now we’re dealing with more pipes, from more practitioners who practice many different ways,” explains the Director of Release Management. “The quality of planning, integration, coordination is all over the map. So bringing it all together to something cohesive, that in the end not just works together, but is properly timed and doesn’t blow anything else up. That is a challenge.” 

4. Misunderstood Risk

Constant change, decentralized responsibilities, and lack of information make it hard for anybody to truly understand the risk associated with any individual deployment, which requires granular visibility into an application's entire stack, starting with the server operating system as well as all the upstream and downstream dependencies. 

The inability to understand risk profiles goes to the core of what happens when you have distributed teams, diverse working methods, and incomplete information sharing—in other words, DevOps without release management. “The amount of moving parts and dependencies is incredible, and unless everybody’s on the same page and you have a flight screen, a radar view of the entire sky, it’s statistically likely that things will break, probably fairly often,” explains the Director of Release Management at a global pharmaceutical company. “The question is what breaks? Is it something you could live with, or is it a real issue?”

Learn how release management can address these challenges by reading our white paper: The Role of Release Management in a DevOps World.