Achieving Enterprise Release Harmony

Enterprise release management consists of one or more individual releases in which some of the planned changes are independent while others are dependent.

If we think of an enterprise release as a song, then the individual releases can be thought of as the musical notes that make up the melody. Just like a song consists of a sequence of musical notes, an enterprise release consists of a sequence of releases that are ordered by their dependencies. If the musical notes are discordant, then the resulting sound will be off-key or off-beat. In a similar way, if individual releases are not scheduled properly, then the enterprise release will either fail or result in unintended consequences.

This article will discuss the problems associated with enterprise release management and ways in which these problems can be overcome, resulting in what I like to think of as release harmony.

Problems with an Enterprise Release

In practice, enterprise release management can be a complex endeavor because it is dependent on many factors, such as the organization’s process maturity, the support team’s structure within the organization, release dependencies between multiple teams or business units, the maturity of the configuration management system, and team coordination.

The scope of this article is limited to release dependencies between multiple teams or business units. Let us first look at a couple of issues that might arise between individual releases.

Take a look at the figure below, which displays a simple enterprise release that consists of three releases in a sequence.

Here, release R3 is dependent on the successful completion of release R2, which in turn is dependent on release R1. Although the figure looks very simple, it may not be the case in real life. It could be that these releases are owned by three different business units that are geographically far away from each other. In this scenario, there are a couple of issues that can arise:

• Release delays

It’s possible that release R1, R2, or both get delayed due to unforeseen reasons. If R1 gets delayed, R2 and R3 will also get delayed. If R1 is on time but R2 gets delayed, then R3 will get delayed. The net effect of these delays is that the enterprise release as a whole will get delayed, resulting in extra costs and wasted time.

In organizations where the processes are immature, release delays happen either because of delays in the development of the product, bugs, or patches, or due to delays in the release planning activities. Many organizations ignore the time required for the release planning activities.

For figure 1, If T1 is the time delay of release R1, T2 is the time delay of release R2, and T3 is the time delay of release R3, then the total time delay of the enterprise release (Te) can be calculated as:

Te = T1 + T2 + T3

In more complex dependencies, the costs and time delays can get even worse.

• Release interchange

In Figure 1, it is possible that release R2 completes before release R1. It could happen under the condition that R1 gets delayed and R2 is completely automated! As a result, the new release from R1 doesn’t get deployed in subsequent releases.

Clearly, there are issues related to release dependencies in an enterprise release.

Solution

To ensure the smooth execution of individual releases in an enterprise release, release managers must identify two buckets of releases: independent releases, which have no dependencies, and dependent releases, which are dependent on another release’s completion (such as release R2 and R3 from figure 1). This way, the independent releases can be executed parallel to a dependent release, saving a lot of time. Dependent releases can be scheduled separately.

Release schedules for dependent releases must be calculated by adding the time required for the development of the associated deliverable, such as a product, defect, or patch, and the time required for release planning efforts.

Figure 2 is a modification of figure 1, where the triangles in figure 2 represent the time required for release planning efforts.

Remember that release planning depends a lot on the size and complexity of the deliverable. A small patch may require less time than a large application or product release, so the time for release planning must be calculated very carefully. The release planning time (the triangle in the figure) will also act as a cushion in case of any unexpected problems during the release.

All the releases must be scheduled in their order of dependencies with respect to the other releases. If any release gets delayed or fails and doesn’t get resolved within the time gap left between releases, then either remove the release (if there aren’t many dependencies) or halt the entire release chain and adjust all the release schedules once the issue is resolved.

It is important to keep the clients and stakeholders in the loop at all times of the release process. That way, they’re aware of any changes to the release schedules, release updates, and any problems with the release.

Conclusion

Enterprise release management can be very complex due to the individual release dependencies. But if the solution outlined in this article is followed correctly, it can guarantee seamless releases. Just as smooth musical notes result in a pleasant melody, smooth releases will result in a pleasant enterprise release.