What place does enterprise release management have in DevOps?

Source- devopsonline.co.uk

Application delivery is challenging for any organisation, but at enterprise scale, it is even more complicated.

Combining and empowering teams across all lines of business, that can be globally situated, to come together to finalise software is complicated – particularly when some of those teams might also work for third-party contractors.

However, there is one, clear goal that unifies these teams, and that is the directive to ‘go faster’, to deliver software more quickly.

DevOps is a methodology that is proving time and again that it can aid organisations in achieving greater speed at scale.

It makes sense; if you can make Dev and Ops work better while breaking up delivery into smaller chunks, there is a benefit to be had.

An integral part of making this realisation is technology-driven; organisations need to adopt agile technologies to increase operational efficiency.

However, a cultural shift that focuses on strong communication and collaboration is also imperative.

By using DevOps to drive change, it can be easy to assume that the role of enterprise release management is no longer needed.

After all, operational oversight can be invalidated by the process of automation. But is this really the case?

Can release management play a role in DevOps?

Is it possible to make multi-delivery pipelines truly autonomous, eliminating the need for ERM at all?

What is Enterprise Release Management (ERM)?

ERM is a set of practices designed to coordinate the software delivery cycle across the many projects that enterprises have running at the same time.

It is orchestrating activities across multiple initiatives and unifying them towards a successful software release.

Areas such as creating, scheduling and coordinating these delivery pipelines all come together under ERM.

A key part of this is delivery release management which focuses on the delivery of the entire product including hardware, software, applications and/or infrastructure configurations.

Additionally, technical release managers focus on the building of application assets, such as the code, the application configurations and the database structures; in essence, the management of development to ensure alignment with architecture and best practices.

Fully aligning the business and mitigating risk are also key parts of the big picture for ERM.

Ensuring test teams are prepared, infrastructure components are ready, and operations are integrated – in terms of not only the team, but also the overall preparedness – are vital.

If a release is looking to make big functionality changes, it is understandably important that the company knows exactly what’s coming, and the ERM manager is the only reliable coordination point for that communication.

Where does ERM fit in an automated ecosystem?

A fully-automated approach can bring lots of benefits and seems like the natural choice in today’s tech driven world, but areas such as governance and compliance still pose challenges.

The goal for most enterprises is not 1000 releases a day, but a well-coordinated release production pipeline to save or at least maximise the investment spent on regulatory tax.

And while automation can help ensure that teams and resources are available, it is the human behind it that oversees the operation as well as discovery and implementation of areas for improvement.

Organisation-wide visibility into changes is what is lacking when DevOps is not fully embraced.

Essentially, anyone can automate – it’s knowing what to automate that needs ERM. It’s the process of combining tools, automation and human management that provides clear insight into each delivery pipeline.

This leads to evaluation and ultimately the implementation of positive changes that drive towards the goal of going faster – a desire which has seemingly no end.

Thinking about all of this as working towards a collective goal, if DevOps and continuous deployment is the holy grail of true automation, it is clear that there is still a place for ERM in this process.

ERM is not going anywhere and organisations looking to streamline need to make it a priority.