The development team works through its iterations until the feature set and quality of the product is sufficient for a release.  Too many organizations, however, define release management as starting from this point.  There are two key requirements easily ignored with this approach: release management has to start prior to development, and the tools and processes available for release management are equally applicable and important for everyone on the product team, not just for the release team.

It doesn't really matter if you're using a traditional or agile methodology.  Release management must start at the start of your release cycle, not at the end of the development cycle.  And proper release management will benefit the entire team through the entire lifecycle.

Managing a Release
Taking a look at some of the issues that need to be dealt with as part of release management, it becomes clear that release management is an end-to-end lifecycle management process.

1. What's going into the release?
2. What are the priorities in case we run into time/resource trouble?
3. How flexible is our process with regard to changing the release target functionality?
4. Which outstanding problems from the previous release need to be addressed?
5. How is the release to be managed to minimize risk and ensure success?
6. What level of verification is necessary and what is that plan to ensure full coverage?
7. Which tool(s) are going to be used to support the release?
8. When and how will we commit a release date to marketing?
9. How do we track our progress against our release plan?
10. How will we generate and deploy/distribute the release artifacts?
11. How do we identify, for the customer, exactly what actually went into a release?
12. How will we track and improve release quality after the release?

Process is critical, but it's equally important to have the tools in place that allow the capture of all release information, and the query of this same information in a manner that helps the team make critical decisions in an efficient manner.  Process must be clearly (and easily) understood by all of the players.  Tools must be easily used by all the players, including all levels of management.

Capturing Release Information
When it comes down to it, tools provide the critical capability to capture release information.  It's not sufficient to identify pieces of data.  Each piece of data must be clearly linked to its place in the release puzzle.  Whether it's a new or modified line of code, the success or failure of a test case, or an internally raised problem report, it must be easy to navigate backwards and forwards through the process lifecycle to identify the impact on and resulting from the piece of data.

When it comes to selecting and using appropriate tools, I always recommend a complete ALM solution - not one sewn together by the CM team.  If the data does not reside in a single repository, the data capture will be more difficult, and the query and traceability even moreso.  Regardless, a next generation tool will address two critical functions:

(1) Pick up data from a user's context
(2) Provide a user interface that allows for automation of traceability capture.

Looking at the first function, it must be easy to specify a user's context in a clear, unambiguous manner.  This may be as simple as telling the tool environment "I'm working on the build that customer XYZ has" or "I'm working on the codeline for release 2 of product ABC".  Generally, and most often, it doesn't have to be more complex than that.

Now when I create a new change, the data is automatically populated with the product and release I'm working on - no finger problems.  When I raise a problem report, it is stamped with the product, release, creator/originator, date and time.  No need to fill in any of these details manually.  When I check out a file, perhaps the tool can even let me know if I need to branch (instead of leaving this to a branching strategy education exercise).  When I do a workspace comparison, the context is implicit.  Anyway, you get the picture. I hope.

With respect to the second function, user interfaces must be defined to allow traceability information to be captured.  So, for example, I don't add a new file. Instead, I add a new file to a directory (i.e. by right-clicking or otherwise selecting the directory object).  I don't link files back to a problem report at check-in time.  Instead, I start a change/update from my problem to do list by clicking on the problem I'm going to fix in order to fix the problem, and then I check out files against the change/update.  I don't create a test case and then associate it with a requirement.  Instead I right-click on a requirement and select "Add Test Case" or something similar.  

When the user interface is arranged in this object-oriented fashion, it allows the tools to automatically identify the traceability.  And of course this is all easiest when a single integrated ALM tool, on a single repository, is used.

If these two critical functions are not provided by your tool(s), you will likely be missing data, have erroneous data, or be missing crucial traceability information.  Ultimately, all of this information is needed at release time.

Querying Release Information
Release management with appropriate tools and data capture will allow easy identification of the following information (not exhaustive by any means).

1. What problems were addressed by the release?
2. What new features are there in this release as compared to the current customer's deployment?
3. Which pre-existing features are currently not working?
4. What are the outstanding problems?
5. How does the new release quality compare to the previous release?
6. Is problem X fixed in this release?
7. What problems must be addressed before then release goes out the door?

The list goes on and on, as I'm sure you know.  But if this information, though present, is not readily available, then the value of the information is reduced.   Information that takes 3 days to compile, cannot be used in the same way as that which takes only 30 seconds.  You can't explore within the context of a meeting if every question you have is going to take days to answer.  You can't answer customer queries in a timely fashion if you can't get at the information quickly.

So it is not sufficient for a solution to have the information that can be mined.  It has to be readily presented in its various forms (graphical, detailed, metrics, etc.).  It must also be possible to identify and navigate traceability links in an intuitive fashion.

Release Management for Everyone
The above questions may be important to the release team, but they are also important to the development and support teams, as are dozens of other queries.  And not just at the release level, but for any build that is produced from the CM repository.

A developer finds a problem that wasn't there a week ago.  He needs to identify the changes that have gone into the code since then.   The quality team wants to know why the problem wasn't detected earlier - is there a missing test case or was testing not completed?  Similarly if a developer finds a line of code that she doesn't understand, she needs to trace it to the reasons that it was introduced.

These examples require the same product information that the release management functions require.  Instead of comparing releases, developers are usually comparing builds.  Instead of identifying the full set of features, they want to know if their feature changes made it into the build.

It's the same ALM integration, the same traceability data, the same process and the same data capture, needed by the release process, that provides key benefits to the rest of the team.  So look at your release management more closely and when you have your tools and processes well oiled, you'll find productivity increases across the board.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment