Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

The Challenges Posed by Parallel Development on Release Management

Written by Michael Sayko

Sunday, 15 August 2004 16:00

Today, most organizations develop software applications as a series of successive releases. Release management is the discipline that encompasses producing and delivering each release. This discipline applies to all software development activities including commercial software development, custom IT software development, and web application development.

Parallel software development is the practice of developing or modifying two or more releases of the same software application at the same time. Today, parallel development is widespread. It occurs in commercial software development, custom IT software development, and web application development.

Since parallel software development entails making changes to different releases of the same software application at the same time, it poses a unique set of challenges for release management. While these challenges are formidable, software development teams can address them. To meet the challenges posed by parallel development, the focus of release management must expand beyond a single release to include all releases planned, under development, and in maintenance.

What is a Software Release?

Stated simply, a release is the set of features of a software application implemented during a software development lifecycle. A release is also the time-bounded activities that occur to implement these features. In other words, a release is both the product of one software development lifecycle and the activities that occur during that lifecycle to make and support the product.

The software development lifecycle begins with the identification of the requirements for a software application, continues through the design, development, testing, and delivery of the software application, and concludes with the post-delivery maintenance of the software application. The software development lifecycle is complete when a new version of the software application ships, replacing the version in post-delivery maintenance.

While described as a series of activities, the software development lifecycle does not have to follow a waterfall approach in which one activity starts when the previous activity completes. It is possible, and even desirable, to divide the software development lifecycle into a series of iterations. Each iteration can be a mini-lifecycle in which a new feature is designed, developed, tested, and delivered. Taken together, a group of iterations forms a release.

What is a Release Management?

Release management consists of the technical and management activities needed to take a release from a set of requirements to the delivery of a software application that implements these requirements.

Release management activities often include the following:

Determining the features to be included in the release
Tracking proposed changes to the features to be included in the release
Managing the software application dependencies within the release
Developing the procedures and related automation to build the software application for the release
Deploying the software application to test environments
Ttracking software defects and their resolutions
Packaging the software application for shipping or deployment.

What is Parallel Development?

Parallel development means a software development organization works on two or more releases at the same time. The most common form of parallel development occurs when an organization maintains the production (or shipped) release while developing the next release. Although the bulk of a development organization’s activities may focus on new development, there is usually a need to make bug fixes and minor enhancements to a release that shipped. Maintenance of a production (or shipped) release is applicable not only to commercial software products, but also to IT and web applications.

The growing pressure to deliver software releases in weeks, or even days, means that software development organizations use parallel development to stagger releases. In this type of environment, work on the release after next starts before the next release ships. This means development of features in the release after next begins before the features in the next release are fully implemented. As you can imagine, this can pose a problem if the features in the release after next must enhance the features under development for the next release. It is the software equivalent of starting to frame the roof of a house before the supporting walls are completed.

How Does Parallel Development Impact Release Management?

The single greatest impact that parallel development has on release management is the need to propagate code changes from one release to the next. Propagating code changes means copying code changed in one release to the next successive release. It also entails making any necessary modifications so that the code changes work in the next successive release without breaking any existing features of that release. Making the necessary modifications in the next successive release is also known as merging the code changes.

In the case where parallel development consists of maintenance of the current release at the same time as development of the next release, bug fixes and enhancements made in the current (production) release need to be propagated to the next release. In the case where the next release and the release after next are developed simultaneously, code changes made for the next release must be propagated to the release after next.

Managing the propagation of changes from one release to the next can be an arduous task. If this task does not receive the proper support, bugs fixed in production can reappear once the next release ships. Alternatively, features completed in the next release may still be unfinished when the release after next ships. In both cases, the source of the problem is the failure to propagate changes properly from one release to the next.

Propagating Changes Effectively Requires Knowledge and Communications

No matter what approach software development teams use to propagate code changes from one release to another, no automated system can replace human knowledge and human communications.

A software developer who propagates a code change from one release (the upstream release) to the next (the downstream release) must understand the code in both releases. The developer needs to know why and how a change was made in the upstream release to make that change work in the downstream release. Additionally, the developer needs to understand how the code works in the downstream release so that the change can be made without breaking any features in the downstream release.

There may not be one developer who is familiar with both the code change in the upstream release and the impacted code in the downstream release. In this case, a developer who made the change in the upstream release needs to work to a developer who is familiar with the impacted code in the downstream release. Together, the two developers can ensure that the code is propagated in a manner that the change from the upstream release will work correctly when added to the downstream release.

The role of release management in propagating code changes is to

Track the changes made in each release
Identify who should merge each code change from the upstream release to the downstream release
Schedule time for code propagation
Verify through testing that each code change was integrated successfully in the downstream release.

Beware of the Silo Effect

While good communication is essential for propagating code changes between parallel releases, poor communication is often the result of the silo effect. The silo effect occurs when each release team works in isolation. Each release team focuses only on the tasks needed to complete their release. The upstream release team pays little or no attention to the changes to propagate to the downstream release. The downstream release team continues to develop code unaware of how to integrate changes from the upstream release.

In the worst case, the consequence of the silo effect is broken functionality following a release. This occurs because the new release is missing critical changes from the previous release.

In the best case, the consequence of the silo effect is a scramble to integrate changes once the development team realizes that critical changes were never integrated in the downstream release.

Understand Build and Runtime Dependencies

An issue closely related to change propagation is build and runtime dependencies. Release management in a parallel development environment requires understanding how a change upstream depends on other changes upstream. A change in one part of the code base may depend on one or more changes in other parts of the code base. This dependency may surface either at build time or at runtime. A build time dependency means code will not compile until the dependency is satisfied. A runtime dependency means that code will not produce the desired results when it executes because the dependency is not satisfied. To satisfy a build time or a runtime dependency, all dependent code changes must be propagated at the same time.

A responsibility of release management is to identify and manage build and runtime dependencies so that they are satisfied whenever a code change is propagated from one release to the next. In the same way that changes are tracked, dependencies must be tracked so that code changes are not propagated haphazardly from one release to the next.

Conclusion

Parallel software development poses a unique set of challenges for release management because of the need to propagate code changes from one parallel release to the next. An essential role of release management for parallel releases is to track and manage change propagation from one release to the next. Since the effort required to propagate changes is not insignificant, time and resources need to be allocated in the release schedule for change propagation.

Michael Sayko is a software configuration management consultant based in Austin, Texas. He is experienced with the practice of software configuration management from having served as a configuration manager on large, fast-paced software projects.

You can reach Michael by email at mss@acm.org.

Set as favorite

Bookmark

Email this