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.