Release Builds

There are two ways to release Theatre Manager to customers. Auto Deployment - a release library is packaged up and placed into our CDN for delivery. This should be targeted to testing (for testing), then support, then selected customers, then all customers according to a timeline based on the type of changes Downloadable Installers - a full installer (containing the same release library) should be made periodically for those sites that prefer to download and self install. If there is a sub-component change like the word processor, that may need an installer. In general, the Downloadable installers do not need to change often and must be a version equal or after the current auto-deployed versions.

The release process for Auto Deployment and Downloadable Installers is similar. There will always be:

• Beta build for internal testing
• Release Candidate for testing within the support team
• Targeted Releases for specific customers with specific problems
• General Release for releases that pass muster in the above three test levels
• Backout Release which is a re-deployment of the prior version, except with the version number rolled ahead of the abortive release.

When code has been designated for potential release:

• a final build of the code will take place using Build without Comments
• it will be placed onto the build directory and new installers built using the automated deployment scripting tool that is platform appropriate:
  • Macintosh: we use packages to make a mac platform .pkg installer (see release notes)
  • Windows: we currently use Installer Vise
• the installers will be tested on all platforms to ensure they run as expected
• the full installer will be placed on the production servers as 'Final Candidate'
• the Support team will download and perform complete installation and usage tests, prior to public availability and notification.

Beta Release

In many cases, one or two beta sites are selected for final testing prior to full notification of a new version - depending on the nature of the changes.

Selection is based on a number of factors such as desire/need for the specific change. Most often this will be one of what is termed a QA tested Development Release.

It could also be a new site where there is a Senior Arts Management representative onsite to watch for any anomalies that were not discovered in the comprehensive testing process. The key in this situation is approximately 8 days of comprehensive observation of the entire application by a knowledgeable person.

If there is a significant number of changes for a prospective public release that are of a nature that warrants a beta program with mulitple venues; a call will be made for willing beta participants who have test servers and can test. This occurs after QA testing have determined that the version is a candidate for public release.

Production Release

When an installer is deemed ready for public release, a number of steps need to occur:

• Release notes are to be created and published in the version release notes that contain:
  • change notes compiled from aggregating and editing the developer checkin notes from the VCS and enhancing with information from FogBugz.
  • a complete steps to upgrade all affected components
  • an estimate of the time that a release will take
  • any special notes or warnings as necessary
• The release will be placed into the 'PriorVersion' directory and given a codified name for Arts Management purposes
• A file on the server will have an entry placed into it that details the version number, release date and codified name. The purpose for this is so that a client can retrieve prior versions in the case a backout is required
• A brief 'marketing summary' of the release notes will be created and placed into the RSS feed on the main help page and published for public consumption