Change: it is what we are all about. The rate of change is something every organization should measure. It happens everywhere in the business but it is often the changes in IT systems that have the biggest impact. Who controls those changes has long been a closely guarded privilege. But today Release Management is a board level discussion because it affects growth at one extreme and risk at the other.
The development teams are tasked with creating new systems to meet the needs of the business. The operations teams are concerned with availability of services. While the motto of Ops might be “if it isn’t broken, don’t fix it” the Dev teams are always eager to deliver “faster, smaller, cheaper.” The tension that results from this is compounded by who Release Management reports to. If they report to Dev, there is pressure to release more and more quickly to meet time-to-market constraints. If Release Management reports to Ops, the pressure is to slow the rate of change and reduce risk.
Not surprisingly then, the relationship between Dev and Ops has too often been adversarial. In any IT shop there are numerous stories told of the developers not testing before releasing and of change managers who never approve any changes.
The DevOps movement tries to address that by stating the obvious truth: without collaboration release management will fail. Getting Dev and Ops on the same page and getting them to understand each other’s needs is just the first step.
Getting Dev and Ops to trust each other is critical. Creating systems that integrate the activities of Dev and Ops makes the biggest single difference. The most effective tool for that is an online release calendar, which shows both Dev and Ops what is planned to release and when. By making the updating of this calendar an automatic byproduct of the development activities, the Operations team is informed early on about proposed and in-motion releases.
Ops now can have a meaningful conversation with Dev about load balancing the release schedule months ahead of the release window instead of the morning before the release. Dev can see the open release holes and manage their project to those dates. And when the inevitable date change happens Dev and Ops stakeholders can be alerted and can react and even sign off to say they have absorbed the impact – or not.
DevOps is a collaborative approach to Release Management. But let me leave you with this thought: who should DevOps report to?
