We build software as part of a system or as its own ,entire product. The goal is to meet the requirements established by the Customer, the Market and/or the Cost/Benefits analysis.
Product releases are meant to move us from some starting point to our ultimate product over a period of time: months, years or even decades. Release Management starts, not with the delivery of software, but with the identification of what we're planning to put into the product. The timing, and content of releases helps us to manage releases so that they are not too onerous on the customer, and so that we stay in a competitive position with our products. Good release management processes will ensure that you know what is going to go into your product, what actually went into the product, and what changes the customer is going to realize upon upgrading.
Planning and Tracking the Release
Release Management starts with identification of what is being developed for a release. You may have an Agile development team or a more traditional model. Either way, you need to plan what's going into your releases. The individual features or problem fixes must be identified and tracked, that is, linked to the requirements/requests which
were responsible for them, and referenced from the changes that implement them.
With Agile development, your planning is in the form of identification of features/problems and prioritization of these. Every week or two, you re-visit your to-do lists and adjust priorities. Your Agile development is trying to keep your development team focused for the next couple of weeks. Your release management is dealing with what you're going to release 3 to 12 months from now, and in the releases that follow.
For successful release management, your efforts must carefully be traced to the features that are completed, and last minute specification changes, typical in a fast-feedback agile iteration, must be adequately captured along the way. In the end, you will have a product, but you need to know what is in the product and what is not. If your ALM tools don't allow you to accurately track this along the way, you're agile gains will be lost to additional delays and inaccuracies in your release process. If the ALM tools are intrusive, they'll interfere with your lean operation.
In a more traditional schedule-based development environment, release planning is done as part of the requirements specification effort. Requirements are identified and ranked by priority/weight. As the customer requirements are turned into a Functional, an initial feature-by-feature effort estimate allows you to plan your time frames. Here again, as the plan is executed, it's critical that the actual development changes reference the features and problems being addressed. Your CM/ALM tools along with your peer review process, can ensure that this happens.
One Release per Customer?
Early on in a product's lifetime, there's a tendency to customize each release to a specific customer's requirements. This is a good thing, not a bad thing. But if it's not handled properly, as I've seen time and time again, you end up managing multiple releases, one per customer, instead of managing your product.
It's important to recognize that the development team and the product design are crucial release management factors. Customization of releases is always going to give you a competitive edge. However, the goal is to customize at the customer's site, not in the development shop. If your developers are creating custom builds
for your customers, you will rapidly discover that your resource requirements grow linearly with the number of customers you have, and that your product complexity grows exponentially.
The development team will invariably have some experience on board. Explain
to them the requirement that customizations will need to be done post-delivery
- at the customer's site. There is actually a whole range of customization capabilities that will need to be delivered. Some need to be done prior to
delivery. For example, platform-specific builds must be created before delivery. The development team needs to be in the habit of identifying which customizations can be held off as late as possible, and designing the software that way. Consider whether the customization is:
- a coding time customization
- a build-time customization
- an installation-time
- an initialization-time
- a run-time customization
Your team must have the goal of moving customizations as far down the chain as possible. Each level you are able to move down the chain will save you significantly on your build and release administration and complexity. Eager programmers might say that they have a nifty way of managing conditional compilations to put the right combination of features in place.