Our Release Management solution is a Metastorm BPM solution that we use for all our development. We use this both internally and in all of our customers' installations to manage the entire Development, Documentation and Release process. As this is used every working day, it undergoes constant revision and updates. As new features are desired by ourselves or our customers, they can be added.
The main purpose of the Release Management system is to manage the Development process. By itself, this has been a very valuable tool for many years. What we have now done is add many features to support our Process Assurance BPM Methodology.
Encapsulating the Documentation aspect of the Development process has been the main driver for the recent updates that have redefined this system. In all Rapid Development environments, Documentation is the most likely victim for exclusion. Typically it is not regarded as highly important. In our experience, for the success of any long-term project, it is absolutely vital.
Our goal was to make the process documenting of the changes made during Development not only easier, but vastly more useful than it had been typically to date. To do this we settled on two main ideas.
Firstly we added Business Rules, to allow non-technical users to define the requirements for various Rules. These can then be easily viewed and linked to Changes as they are made. In this way the Specification can be directly linked with the Development.
Secondly, we added the ability to document Design and Development details for every Change for each Component. This serves several important functions. It forces the Developer to clearly detail what has been done, making Reviewing much easier; it clearly details all changes made, including impact with other Components and other systems; it provides a complete history of all changes made to the System. Together, the benefits are enormous, and we believe the additional effort required to maintain this is as small as it can possibly be.
System Release Goals documentation
Goals can be set for each System Release. These can be referenced by each New Feature to demonstrate the Goals it supports. This follows our BPM Methodology, and ensures that all Features actively support documented Goals.
Business Rules documentation
Business Rules can be documented, including Pre and Post Conditions for events. These are entered and reviewed and refined, then accepted for inclusion. In this way the complete set of Business Rules for each System may be fully documented.
New Features and Faults
All New Features and Faults are entered and documented. These follow through the Investigation, Estimation, Development, Review and Testing steps. Every New Feature and Fault is linked to the Release it is developed for.
All Releases are numbers with Main, Point and 'Patch' release numbers. There is also an iterative 'Test Build' number for each iteration of Testing. Each Release follows Planning, Development, Testing, Deployment, Review and Acceptance steps. There is also a Rollback option in case it is required.
All dependencies with other systems can be documented. Each System Change can refer to changes required in other systems. This generates full documentation of interdependency between Systems.
Deployment Instructions & Testing
Deployment instructions are completed for all Deployments. These are also tested in the Testing steps, and documented during actual Deployment.
Deployment and Rollback management
Deployment of systems is tracked and documented. Instructions, times and histories are fully detailed and recorded.
Each Component in the system can be listed. All System Changes document the changes made to each Component in order to fulfil the change. This creates a complete set of technical documentation of the System as a whole. Each Change that is made for every Component is fully documented by timeline. This includes full reference to the reason for each change, and each change to related Component to support the relevant Feature.
Design, Development, Review & documentation for Component changes
All Component changes are entered initially as a Design during the Estimation phase. This is then added to with the details of changes made to each Component during the Development phase. During the Review phase, review comments are added. This generates a complete history of each Component change, as well as the review, which typically also includes suggestions for future enhancements and details to help future Developers.
Testing, Test Cases & Regression Testing
Each Release is tested, optionally with associated Test Cases. If any Change fails the Testing process, the Release is returned and a new cycle of Development and Testing is initiated.
Ad-hoc and repeating Task for System maintenance
Tasks may be set for all activities on a System outside of the main Release process. This may include one-off items such as software upgrades and regular items such as database maintenance, log inspections and performance testing.
How to get it
You can download the Solution here for free:
Please note that this was developed in Metastorm BPM version 220.127.116.11, and may not be compatible with any earlier versions.
1. Deploy the included Libraries from the Libraries directory.
2. Deploy the Solution itself from the Release Management directory.
3. Log in to the system as a Metatsorm Administrator
4. Find, open and submit the 'Execute Outstanding SQL Scripts' Admin Form in the 'Release Admin' process.
If you have any difficulties, please visit out Support Forums: