Release procedure

Before a new version of a database application is deployed "live" it is thoroughly validated, documented in "Release notes", then formally archived.

Release Notes

Release notes can serve two separate, but overlapping, functions; user documentation and design documentation. In each case the amount of detail may vary depending on the customer's needs and the complexity of the database.

• For the user: new and changed functions are described from the user-perspective, with screen shots of forms and reports where appropriate. Any bug-fixes and performance enhancements are documented.
  
  
• For the designer: design changes are described in detail, including lists of objects which have been added, removed and modified. Changes to the back-end database affecting compatibility with the front-end are detailed. Any parts of the design which are particularly complex are documented in greater detail.

Click here for an example of a typical set of release notes.

Validation

A series of tests are performed to ensure that new functions work correctly and that the changes have not impacted the existing design. With good design this process should only throw up the odd surprise. Any bugs or performance issues are usually fixed before finally releasing the software; any observations or suggestions for future enhancements discovered during validation would be recorded in the release notes.

• Each item in the release notes is tested thoroughly to ensure not only that it works as intended, but that it cannot be "broken" by the user! Such tests may include: entering bad data, pressing buttons when data they rely on has not been entered, closing related forms unexpectedly, etc.
  
  
• A less exhaustive overall validation process is applied to the rest of the database. With the use of good object-oriented design techniques interactions between different sections of the database are usually minimal.
  
  
• Performance testing. A series of benchmark times are taken and compared with times taken on previous releases. These tests ensure that new changes do not slow down other parts of the database and that performance does not degrade as data volumes increase.
  
  
• Multi-user testing. Interactions between users are considered during both design and testing to ensure that performance and data integrity are maintained under all conditions. Validation may include attempts to "break" the system by having two or three users trying related operations simultaneously.
  

Archiving

Each release is saved in a release directory containing:

• Front-end application database
• A compatible sample back-end database
• Release notes
• Other relevant documentation
• Other relevant source data (bitmaps, imported data, etc)

The release is archived to CD, one copy being stored off the premises for safekeeping. The release can be rebuilt with compatible data at any point in the future using the files stored in the archive should it be necessary for test purposes.

A standard feature of our designs is the error logger. Should a visual basic error occur for any reason it is stored in the error log, together with the date, time, database version and other details. This information is used in conjunction with the archived release information to quickly and accurately reproduce the problem and design a cure.

Send mail to webmaster@tindalldatabase.co.uk with questions or comments about this web site.
Last modified: May 09, 2004