Even in today’s modern software environment, most releases are managed using (many) Microsoft Excel spreadsheets. Other tools include SharePoint (shared calendars and lists), in-person meetings, powerpoint decks. Organizations can also make use of application lifecycle management (ALM) and IT service management (ITSM) tools such as Jira and ServiceNow.
In most enterprises, the release management process uses a combination of several of these tools. This leaves organizations in the dark about too many aspects of a release for it to be an effective strategy: There’s no clear unified picture of risk profiles or dependencies, no release orchestration and no way to visualize how projects are moving through the development lifecycle. It should be clear that this isn’t the best way to manage releases, but what is?
Moving beyond Release Management myths
With organizations moving faster than ever, long-held ideas about release management are swiftly becoming out of date. This includes assumptions like:
- You can have one standard process. Different teams have different capabilities and work with different parameters. You can have categories of releases and templates and frameworks for teams to work with, but rarely a single standard process.
- Having one DevOps toolchain pattern resolves all problems. First off, good luck in standardizing the DevOps toolchain across an organization; while it’s conceivable all teams use a single product backlog platform, different programming languages require different testing tools for example. What you need is a common architecture and a way of managing the data from heterogeneous DevOps toolchains.
- It’s about code deployment. It’s actually about making sure nothing goes wrong at the critical moment when the code deployed is released to the customers. It’s about coordinating cross team efforts to reduce risk.
- CABs and Status Meetings will manage everything. They can, but they can also cause horrible delays in flow and add very little value to the teams as well as the customers. It’s best to empower the team to manage themselves through peer-review, be autonomous from others and automate what you can for assurance.
- Release nights/weekends are a good thing. In the sense that you might not interrupt service, yes. In the sense of everything else, no. They are unpleasant for everyone involved and cause long term cultural problems, burnout and employee disengagement.
- We need someone to manage a release calendar. What you need is to make release activities visible so that conflicts are easily spotted and managed. Nobody wants to be a calendar monkey. There’s tools for that.
- No changes are ever allowed to a planned release. This is a good principle BUT reality bites. What makes it easier to handle emergency changes and adjustments is having a comprehensive handle on what’s happening across the organization and being able to see where there’s some wriggle room.
The modern way – value stream management
The value stream – all the activities that generate value for a single application – is the fundamental unit of software development. Each application has exactly one.
Several release trains can be working on one value stream, a single release train may incorporate several value streams, or it can be 1:1. This depends on the complexity of the application and the interdependency of value streams.
Organizations face the challenge of reconciling the complexity of enterprise management with the relentless change the market demands. Focusing on the value stream rather than the release allows for business and IT alignment at the enterprise scale.
Value stream management zooms out to the bigger picture. As software delivery has come to focus on the value stream instead of the project or product, management methods should also expand to look at the value stream in its entirety. This can’t be done by roughly hammering together a hundred different applications.
Best of breed enterprise release management tools, such as Plutora, enable release managers to take an end-to-end view of their value streams. The entire value stream becomes visible, risk management becomes more transparent and release plans can be standardized.
What makes a good Release Management tool?
Release management best practices require dedicated tools that provide cross-functional collaboration, real-time status visibility and dependency information, all in one place. Release management tools should strip away complexity, help organizations manage risk and understand the entirety of their application suite—in a way that does not require manual updates, like a spreadsheet. Here’s a look at what functionality you need from a true release management tool.
- Make Release Train Visible: Release management tools need to make work visible for release managers as well as those who they interact with. DevOps teams, environment managers, executives and more need a full picture of a Release Train. When work is visible to all these constituents it is possible to effectively collaborate.
- Create and enact Release Plans: A release management tool needs allow a release manager to create and enact a release plan. The release management tool must allow the release manager to document the activities of a release, which team will carry out which activity, upstream and downstream dependencies, and how features will flow through the release pipeline.
- Strip out unnecessary complexity: A key goal for any release management tool is to manage and reduce organizational complexity. Especially at enterprise scale, release managers are expected to track hundreds or even thousands of applications, each with a separate schedule, team and development style. Your release management tool should strip away that complexity and give you a single dashboard to visualize everything that is happening across your entire application suite.
- Manage Risk: A release management tool needs to be able to assist a release manager with risk management. You must be able to see how applications depend on each other and on other resources like databases and persistent storage, so you can see in advance how changes in one place might impact other parts of your application. The release management tool needs to be able to communicate to the release manager how a delayed or changed release will impact other releases.
- Manage Environments: Release management tools should have the capability to book and manage environments. Release managers should be able to understand if there are scheduling concerns or security or compliance risks associated with the target environment that need to be addressed before the application is developed.
- Enforce governance: A release management tool needs to be the guardrails on the release management process. Tools should not allow the release train to move on to the next stage if governance requirements have not been met, tests have not been passed, or the right stakeholder has not signed off.
- Real-time, automatic updates : Your release management tool needs to work without extra effort from developers regardless of the development method. Release management done right is a way for small teams or individuals to zoom out and get the big picture of what is happening across the entire release pipeline —and this is only possible if information is updated in real-time, automatically, without depending on manual data entry at any stage.
- Track project history and compliance: True release management tool provides a history of project changes that ensures regulatory compliance. It should be possible to see exactly who has carried out every action and when that action happened.
- Integration with your software lifecycle management tools: Modern software development teams already rely on a series of tools to automate various stages of the application lifecycle, remove the risk of human error and speed up time-to-value. Release management tools should provide a way to connect all of the tools development and operations engineers are already using. These disparate tools are often poorly integrated with each other and don’t provide enough information to manage the entire lifecycle effectively.
The bottom line is that a release management tool should give you a way to zoom out on your entire release pipeline and get the big-picture view of bottlenecks, feature and activity status, potential application interactions and overall risk profiles. A spreadsheet will never be able to provide that type of information or to update it in real-time.
Release management at enterprise scale is both complex and fast-paced. The right tools provide the organizational guardrails and visibility to make sure releases are as close to on-time as possible, with the lowest risk profile as possible.
Case Studies in Release Management
Intelligent release management powers DevOps and digital transformation as many companies are discovering. Here are a few of our favorite stories:
- “Prior to Plutora, people frequently asked for more time for functional testing and they would be fire fighting. But now, I can see which pieces haven’t been accepted into the release by the respective product owners.” Director of Release Management at HealthFirst
Read more - “Plutora helped us produce 11 enterprise releases this year—up from 4 major and 4 minor releases 2 years ago—with only half the staff.” Enterprise Release Manager at AMP
Read more - “We now have improved the use of time and resources within the IT department. By improving our efficiency and productivity with Plutora, we have removed the dependence on spreadsheets and improved our quality and predictability.” Portfolio Release Manager at United Energy
Read more
Curious what the best-in-breed enterprise release management tool could do for your company? Schedule a demo today.