We have discussed in my last post “DEVOPS and Continuous Change” on the benefits of doing shorter and swifter runs instead of managing a few ‘Dinosaur’ releases. We have also touched upon the way to go about multiple releases by identifying component /functional dependencies without impacting functionality and the expected savings of time, resources and cost, reaching the goal of rapid delivery of software.
It’s common to find a formal Release Management (RM) team in large organization, with a lot more of medium and some small ones following suite. We will not touch upon the benefits of having a core RM team helping plan and manage the complex journey of change from the handover of code by the Application teams, packaging and deploying across testing environments by Operations, validating testing signoffs, risk analysis, impact assessment and ultimately ensuring a successful Production deployment.
Rather, let’s delve deeper to understand how this Confounding or the Third variable called RM fits into DEVOPS. In my opinion a very important actor which neither belongs to DEV nor OPS!
I would call Release Management a catalyst in true sense, which enables change without itself undergoing such change, a neutral team dedicated in managing the change by brokering a formal hand-off between DEV and OPS.
RM teams traditionally have been the most underrated, with the DEV and OPS hogging the credit of every successful run to production. They converge the business understanding of new features or fixing a functionality break with the Development team’s new version of code release or the Operations expectation of infrastructure upgrades which will also provide an enhanced user experience advantageous to business and development.
So, back to my question, where does RM team fits in the cozy DEVOPS selfie?
Wouldn’t it be incorrect to ignore RM from the DEVOPS equation?
I would take the liberty of stating that the DEVOPS movement in an organization should be owned, driven and determined by RM, adding Change/Configuration and Release management expertise to the existing cross-functional mix of the DEVOPS team.
RM should be driving this collaborative approach to rapid delivery, bringing together the right mix of people from both sides and ensuring efficient use of resources, empowered and with executive oversight supporting hard decisions.
They would be able to add value in this rapid delivery process, by not just tasking them with managing a release cycle but empowering and enhancing their capabilities. RM team under the DEVOPS banner should also be involved in these broad points below:
- Prioritizing the book of work, creating trade-off between Business needs and Development delivery.
- Understanding complex business requirements along with adhering to geographical and geopolitical needs and rules.
- Distributed Set of applications, architectural complexities, interdependent and independent components and dependencies,
- Complete awareness of the infrastructure landscape, scalability, capacity planning, migrations.
- Release planning, calendar management, process adherence, true agile sprints, optimal resource utilization, Contingency or Rollback strategy planning.
- Post deployment/release lessons learnt, retrospection, streamline or integrate processes after every run.
- Ensuring consistent message is sent across that the DEV and OPS are not adversaries rather, partners in this collaborative approach of software delivery.
- Management reporting along with any risks assessed or highlights deficiencies.
This take is based on the many DEVOPS discussions which I have come across where there is no mention of RM or is being assumed as ‘part of DEV and works with OPS’.
My disagreement on this thought process is not about to which group it essentially belongs or will be part of, but in assigning an inconsequential role to RM in the whole release journey when in fact they should be the drivers!
Thank you for your time.
Visit my blog for earlier posts http://askhurram.com/
Read On, Live On.
