How to Reduce the Cost of Managing Releases

Managing software releases across a large enterprise can be costly. Your organization has to employ several release managers and teams of people dedicated to testing and environment management. If you haven’t stepped back and thought about cost over the last several years you might want to take some time to think about how you can optimize your approach to release management. This post is about finding ways to minimize the exponential growth in release-related costs that can accompany scale.

If you are like many in the industry you understand that the costs of managing so many simultaneous releases is getting out of hand. Here are a few suggestions for reducing the costs associated with managing releases. They range from high-level recommendations such as hiring a release manager to lower-level recommendations about technology standardization.

1. Hire an Enterprise Release Manager

Large organizations understand the necessity of application release managers. Application release managers manage the delivery of single subsystems or groups of highly related projects. They work on sequencing release activities as a system nears a complex release event, or they create the necessary governance frameworks to support more frequent, self-service releases. Application release managers work on removing obstacles for individual teams and they also deal with conflict resolution as teams are often competing over a limited set of testing environments and resources.

Application managers can decrease the time to market for single applications, but they are rarely in a position to influence release management across the entire organization. If an organization wants to empower someone to think strategically about release process improvement across the enterprise they need to hire an enterprise release manager. An enterprise release manager occupies a role that has visibility across multiple departments and multiple application development teams and this person can implement many of the recommendations outlined in this article.

It might seem counterintuitive that hiring a new level of release management is an essential component to controlling release-related costs, but without an empowered and central enterprise release manager it is difficult to recognize opportunities for greater efficiency as departments and projects are often forced to focus on short-term deliverables.

2. Schedule Highly Dependent Releases Together

This advice may seem to fly in the face of working toward smaller, more independent software projects all releasing software with increased frequency, but sometimes it makes sense to coordinate multiple projects into a synchronized release cadence. If you find yourself synchronizing the same projects week after week, you might gain some cost savings by consolidating release management for these projects and scheduling projects as a unit.

Achieving more independence across application development groups is an important goal as organizations embrace on-demand, self-service release models. But, you have to balance independence against the reality of a large software enterprise delivering highly coordinated change across multiple development teams. If you have multiple, independent teams delivering software at the exact same time to similar systems you should consider consolidating resources and release timelines.

The pros of scheduling highly related releases together are a reduced number of meetings and less duplication in planning across your teams. The downside to this approach is reduced independence. Just as teams are ready to move independently you are telling them to coordinate toward a single release event. It is a fine balancing act between independence and release confusion, sometimes a company can save money by admitting that coordinated release events might be the best way to manage risk and reduce costs.

3. Splitting Up Monolithic Release Events

This next piece of advice may appear to conflict with the previous advice, but in the last section we recommended combining projects that should be together as a way to conserve resources. If everyone is forced to release software together than independence might cost you more over time.

Conversely if you have a number of highly independent projects that are very loosely connected and you force them all to use the same, synchronized release schedule you can face the opposite problem. Sometimes too much consolidation costs more than the alternative. Think about several software projects being forced to align with a once a month release event. If one of your projects is independent and is ready to support a weekly timeline letting that project move independently may free up resources as some of your teams are delivering software with more frequency.

The problem with synchronizing release schedules across projects that don’t have much to do with one another is that you are creating a model that encourages teams to stop and wait for the release process. “Well, even though we’re ready, we don’t release for another two weeks.” If you find yourself coordinating releases between projects that don’t have strong dependencies you could save your organization money and time by letting some teams move toward smaller, less risky, more independent release trains.

4. Define Standard Governance Gates

If your organization manages more than 5 software projects there is a good chance that many of them have common decision points and governance gates for release management. If you have several web applications to deploy they are likely being tested against similar databases and systems, and your Go/No-Go discussions may involve the same operations and support teams.

Define a common set of governance gates across similar projects so that individual application project managers don’t have to start from scratch. If you define common governance in a shared tool like Plutora you can apply governance gates to all projects automatically the next time they create a release plan from a common template. You’ll also make sure that you have a central mechanism for defining what is and is not acceptable. If you have centralized governance gates and conditions you can specify parameters before software is launched. For example, you can establish a baseline that all code must have unit tests and full integration test coverage, or you can state that no production release can make retrograde progress in performance unless it has been granted an exception by senior management.

Establishing central governance gates moves responsibility out of individual projects, gives management a new tool to define enterprise standards, and avoids a condition where several teams have to invent quality standard independently. This is the key to reducing release-related cost: standardization.

5. Establish Common Templates for Deployments

Maybe you support 10 web applications and 5 databases alongside three systems using Sharepoint? Or maybe you are a .NET shop and you have a number of applications that use ASP.NET? Whatever you do it is likely that several of your projects use the same production frameworks and the same production hardware. It is also likely that your teams all follow similar procedures when deploying software to production.

Don’t recreate playbooks and deployment scripts for every single application. Reuse deployment playbooks and release checkpoints to support common infrastructure and application architecture. Doing this will dramatically reduce costs because you can centralize release engineering. Yes, you may need to have several application release managers, but if you standardize on common templates for deployments or if you require all projects to use a common approach to deployment automation you can save significant resources.

6. Use Plutora

When you start using Plutora you’ll quickly come to realize that this tool was designed with cost-savings in mind. We give you a centralized view of your release pipeline, we allow you to model and track both engineering and management resources, and you can use our software to identify opportunities to consolidate release efforts and move toward a lighter-weight approach to release management.

Most organizations have yet to model and keep track of just how much effort goes into environment and release management. With Plutora’s consolidated view of release-related activities you start understanding just how much duplication is present throughout your organization.