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

Auto Deployment Builds

Set Version in Theatre.lbr

in Startup_task method, set the following three items:

  • Version Number according to the versioning terminology.
  • Migration Step to be the minimum allowed TM server version that the client will work with
  • Release Date to be the intended release date
This will be used by the manifest.json file to determine actual eligibility for the release per the last item in this checklist.

 

Privatize/Lock the Library classes.

Auto Deployment builds require the Theatre Manager library be built without comments and to be locked except

  • All Report Classes - excluded using filters in the Studio development tool
  • Password Classes - excluded using filters in the Studio development tool
  • Systems Classes - excluded using filters in the Studio development tool
  • the 10 or so specific classes that are marked with a bullet and are easily found by sorting the classes. An example is shown below

 

Testing With Runtime on Test Environment

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.

 

Building Auto Deploy Package

  • Rename the Theatre.lbs library to be TheatreXX.YY.ZZ.lbs where the XX.YY.ZZ matches the versioning terminology.
  • Use the Studio development tool to make a specialized JSON payload, encode and zip it into a file.

    The menu is Developer->Make AutoDeployment LBR's for 2ndGen

  • This will:
    • ask you for the location of the libraries and reject if not in the proper name
    • encode, compress and zip the file for you into the desktop
    • Display a message telling you to open terminal and paste the clipboard into the command line to generate a SHA384 hash
  • Open Terminal and paste from the clipbard. The command should look similar to below. When you hit return you will get the proper SHA-384 checksum for the zip file.

 

Staging deployment package to the CDN

  • Login into Digital Ocean and go into the artsman-updates CDN folder. Drag the TheatreManager-XX.YY.ZZ.zip file created in the previous step to the Digital Ocean CDN and make sure to set the permission to public

  • Also, log into the web server via seafile and push the release candidate into the folder as shown.
    • You can place the file into both the production and test folders.
    • A release will not proceed until the manifest.json file is edited.

 

The Manifest.json file

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:

  • Via the Test release manifest and directories:
    • all developers and verified for deliverability and changes.
    • all support staff and verified in course of normal use.
  • Via the Production release manifest and directories:
    • the specific customer(s) that need the change immediately to correct their issue
    • all customers subsequent to verification of each release stage

The components of the JSON file are:

  • Major and Minor version numbers that this release is applicable for according to the versioning terminology.
  • Minimum TM Server to co-ordinate that the release will not download unless the TM server is at that version
  • Release Payload - the name of the release
  • Permitted Customers - the licensee's that are able to download the version. If this is incorrect, nothing will download to the customer.
  • SHA384 checksum - of the payload. if this is incorrect for the version, nothing will download
  • CDN Location - the URL of the file to download. if this is missing or private in the CDN, nothing will download.