The ITSM Review will be performing a deep dive review of Enterprise Release Management tools.
This article provides an introduction to Enterprise Release Management (ERM) and a high level summary of typical functionality.
- This group test will be conducted by Rebecca Beach, our ITSM Analyst, and Rob Spencer, Change and Release specialist and vice-chair of the UK itSMF Transition SIG.
- We’ve also included a few examples of providers who offer ERM capabilities – please let me know of any other suggestions.
- If any suppliers wish to participate in our Group Test please contact us before 30th September 2014.
- Learn more about our Group Tests.
- Read our back catalogue of completed Group Tests.
Introduction to Enterprise Release Management
By Rob Spencer
How do organisations plan tens or hundreds of releases a year across project delivery, vendor patching, infrastructure changes and more? How do they manage competition for access to test environments, ensure they spot colliding production releases in good time and avoid overbooking their test teams?
How do they articulate this enterprise-wide release roadmap to senior stakeholders, customers and IT staff?
Traditional answers to these questions usually take the form of project plans and spreadsheets. They rely on regular meetings between project office, operations & technical staff to keep them in sync, and are rarely, if ever, accurate in real time.
Today, a new breed of release management planning tools is emerging. Enterprise Release Management tools are agnostic of functional requirements or constituent change requests, and they don’t manage the actual deployment of code. They simply allow the entire IT organisation to track and manage the entire portfolio of releases across all environments. They have the scope breadth of a Change Schedule, but go into more detail.
At their simplest, they are a single source of the truth for the multitude of spreadsheets they replace, but most can pivot this data to provide people with the information they care about in customised and intuitive views – from CIO roadmaps to a test manager’s forward work plan.
Ultimately, they give Service Operations a reliable, realtime view of all upcoming releases with at-a-glance assurance that the right governance has been completed for each. And since they span both development and operations, many are starting to be called DevOps Release tools.
What does an Enterprise Release Management tool do?
- Plans (and scopes) a release – Allows the construction of an end to end release plan following a user-customisable structure which could map to eg. an organisations’ project governance gateways. Should be able to record both governance activities/milestones as well as physical activities in multiple environments (deployments, test runs etc). Ideally should be templatable and re-usable.
- Plans ALL releases – Takes the individual releases and plots them against a common timeline to spot resource over/under utilisation, go-live collisions and tells operations when to brace for action.
- Manages environment & resource usage – Pivots the data from all releases and show an environment – or resource -centric view of the same data. Helps answer questions such as “what’s happening in our Pre-Prod environment next week?” or “can I deliver everything I promised?”
- Presents data in various views depending on audience – The steering committee has different needs to those of a test manager, and the project needs to be able to see anything relevant with a few clicks. Does the tool allow varying levels of detail to be presented over user-defined timescales in a clean and coherent way no matter the format?
- And not forgetting… – Role based access to stop people from seeing the wrong things (or changing them), the ability to dynamically import and update change requests from other tools (data exchange mechanisms such as XML and RESTful APIs are becoming the norm in service tools).
To test these, we’re constructing an entire fictitious company with a busy year of releases including new system deliveries, infrastructure refreshes, monthly & quarterly patching to cloud and on-premise services. We’re covering both agile and waterfall development & delivery methodologies, and even introducing some DevOps practice. We’re sharing this case study with the participating vendors, and we’re also going to make our own spreadsheet versions of the plans (which we won’t share with the vendors in advance). Our case study also includes some fairly thorny problems which a typical organisation could encounter eg. scheduling conflicts, people not following process and people whose idea of planning is far removed from the reality of their customers’ needs.
Here are some tools we are aware of in this area.
- Plutora Release Manager
- Serena Release Manager
- Service Now (Release Module)
- XL Release Coordinator