Habit #4: We have a release manager

There is no one way to do DevOps – you can’t simply follow a checklist or step-by-step guide. Companies need to adapt the general concepts and principles of DevOps to suit their needs and teams. But, there are some bad “habits” that frequently pop up when doing DevOps. In this blog series, we’re unpacking seven of those scenarios so companies can learn how to do DevOps right. In this post, we’re exploring why a release manager isn’t necessarily a helpful role.  

In many organizations, the development team writes code and then passes it onto someone else, usually an operations team, in charge of the (physical) systems that it’s supposed to land on. A release manager coordinates this process, which means there are multiple handovers. This approach is a traditional way of working and often causes unnecessary delays.    

For example, having another team/person in charge of the release takes autonomy away from the development team. Any issues that arise require significant back-and-forth communication, which wastes time. In this scenario, the release manager does not add value, other than putting pressure on the development team to resolve things faster.  

In a DevOps organization, the team creating the artifact is responsible for the complete lifecycle of that artifact, or at least from ideation to production. Creating teams with both developer and operational skills enables everyone to know where and how artifacts should be deployed. Communication is mostly limited to the team members they work with on a daily basis, which saves a significant amount of time. The team is aware of where production stands and can problem-solve together if issues arise.   

Automate, Automate, Automate!   

This applies to all DevOps teams, automate as much as possible. The more we automate, the fewer mistakes we make. In this case, automation really helps decrease some of the bottlenecks that arise from having a traditional release manager – manual processes, documentation, and redundant communication.   

While an organization transitions to a DevOps way of working, a release manager can play a role in the communication across the company and potentially towards customers. Release managers can also support other aspects of the workflow like overarching quality and security checks, audit processes, and ensuring products comply with company guidelines. Ultimately, however, the optimal DevOps way of working is to phase out the role of release manager by creating teams that can manage the full production process and automating as much as possible.   

Ready to learn more about doing DevOps right?   

When transitioning to a DevOps way of working, old habits tend to sneak into your workflow here and there. That’s natural! This blog series is partly to highlight just how easy it is to slip into old habits without even realizing it. Contact us to continue the conversation about how best to spot and change old habits that have crept into your workflow.  

Tune in next time to find out why "failure is not an option" is the fifth habit of a highly in-effective DevOps team.