There are two ways to release Theatre Manager to customers.
|
The release process for Auto Deployment and Downloadable Installers is similar. There will always be:
When code has been designated for potential 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.
When an installer is deemed ready for public release, a number of steps need to occur:
in Startup_task method, set the following three items:
Auto Deployment builds require the Theatre Manager library be built without comments and to be locked except
For beta testing, test the library with the Theatre Manager runtime on your machine Once that is done, build a beta auto deployment package and release to developers.
The menu is Developer->Make AutoDeployment LBR's for 2ndGen
The following shows the constituent parts of the manifest file (json format) that needed to be edited for a release to. occur. If the manifest is not a completely valid JSON file, no release will occur.
A release should be done in four stages. It should be gradually released to:
The components of the JSON file are: