Konsensys ReleaseManager^TM

Konsensys ReleaseManager^TM automates the build and configuration management tasks for companies having hundreds of software developers.

THE PROBLEM

A large software company or division of a large corporation are composed of teams, each team is responsible for the development of a product. Each product is either released "external" to the company/division or released "internal" to those groups producing the "external" products.

For example, a company producing CRM (customer relationship management) software might have a sales force automation product, marketing programs product, a customer support product, a defect tracking product, etc. that are sold to other companies. There are also teams that produce components that used by all of the externally released products. As a group, the internally released components are sometimes called a "core" or "platform", which the various applications sit on top this platform. Individually, each internally released product is sometimes called a "service".

The key release problem large software companies and divisions face is destabilization during development. This destabiization results in large schedule delays and cost overruns. This destabiization is from two sources:

1. New changes checked into a CM (configuration management) system.
2. Cross-product dependencies.

New changes checked into a CM system destabilize other teams.

The industry standard means of limiting this problem is called "branch promotion", which is a 4 step release process:

1. A developer releases (checks in) changes into a "feature" development branch.
2. When the feature team deems the quality of the of work ready for release to the rest of product team, the changes in the feature development branch are released (integrated) into the product development.
3. When the QA organization deems the product development sufficiently good, the code in the development branch is released (integrated) into a release branch.
4. When the product manager deems the code in the release sufficiently good, the code is released (integrated) into a service pack release branch.

There are many variations on this, but the basic concept is that of "quality gates", where code must pass some quality criteria before being released ("promoted" into a branch that is visible) to a broader range of users.

Cross-product dependencies destabilize other teams.

The medium-sized group has the triangle-dependency problem, where external products A and B both depend the internal product, C. Changes in C to accommodate changes in A, destabilize B.

The large-sized group has the diamond-dependency problem, where external product P depends on internal products A and B, which both depend on the internal product, C. Product P can only ship with one version of C. Are A and B both using the same version of C? Further, product P might be using a hundred such components, many having diamond dependencies.

Some build tools like Apache.org's Maven, have a dependency checker to locate such dependency conflicts. But, it is Java-language only. And, a cost-efficient process prevents such conflicts in the first place.

For example, product A is about to release with the internal product C. The cost of upgrading component B to work with the new version of C or even just the QA cost of re-certifying against the new version of C shortly before a release adds unexpected QA costs and delays the release schedule of B. The time to fix such dependency conflicts in large organizations, is measured in months (a new, full round of QA testing on just one product is typically a fixed cost 2 months).

Long release builds.

One can speed release builds by breaking the product into a lot of small components that can be built separately, each with their own release schedule. Thus, a release build only requires building the small pieces that have changed. Further, having separately built components makes it easier to build in parallel, which can greatly reduce build times.

The problem with this that it exacerbates the triangle and diamond dependency problem, because there are now many more components sharing other components. It is important to find the right balance the amount of breaking into small separately built components to speed builds against making making configuration management valid. The bottom line is that having the "correct" build (no version inconsistencies in the shared components) takes priority over the "speed" of a release build.

THE SOLUTION

• A known-to-work branch promotion process that reduces destabilization caused by changes checked into a CM system.
• A known-to-work directory organization for code that prevents most triangle and diamond dependency conflicts and makes it easy to break products into smaller, independent components for faster builds.

Konsensys ReleaseManager^TM probably doesn't support "your" current release process, because no two companies have exactly the same process. Thus, the issue becomes a choice of either spending a lot of time and resources customizing a Release Manager product to fit your processes or reorganize (refactor) your code to work with the Release Manager.

It is better to reorganize your code to fit the Release Manager.

• There are tools now that can reliably automate the refactoring of your code, which your developers are probably using already (come as part of IDE's now, like JBuilder and Eclipse).
• The fact is that you are reading this because either your current release automation is either not working well for you or you don't have an automated release process yet and are looking for something to purchase rather than develop in-house. In which, case it's better to go with a Release Manager product that is known to work well.

The fact is there is no "best" release process. There are many good release models, each with advantages and disadvantages. The developer of Konsensys ReleaseManager^TM has been in charge of configuration management and release since the early 1980s on projects with hundreds of developers. Konsensys ReleaseManager^TM automates a release process refined over the last the twenty years that is known to scale from fifty developers to several hundred developers.

Konsensys ReleaseManager^TM is designed to layer on top of a CM system that is "branch-oriented" like Perforce Software's Perforce^TM, IBM's ClearCase^TM, or the open source, Subversion. The first version of Konsensys ReleaseManager^TM will be integrated with Perforce Software's Perforce^TM.

Konsensys ReleaseManager^TM is a web-based application designed for product managers and engineering managers to perform common tasks without having to know anything about the CM system. The manager will presented with a few simple menu items to choose from such as:

• Create a product development branch
• Create a feature development branch
• Create a prototype development branch
• Create a release branch
• Create a service pack branch
• Add/Remove someone from a branch access group
• Label a release

Of course, the Konsensys ReleaseManager^TM will come with a build system and integration with Konsensys BugsMe^TM Defect Tracker (defect tracking system).