WCS Release Procedure

Introduction

The purpose of this document is to document the release process for WCS

Release admin

Release Spreadsheet

The currently released versions of the WCS system can be found in:

WCS Release List.xlsm

The spreadsheet contains a list of all the packages available for release, the versions of the RDT, WCS and Maintenance EXE's and the rdt1 (RDB) and log/log1 (LDB) Database versions within each zip:

It also contains a list of each log - with a description and functional area - contained within the zip/release:

For each version, an "L" (Live) and "T" (Test) will be in the appropriate row/column for the client:

Each time a release is made, the L/T will be moved to the appropriate row.

Release Directories

The following directories are relevant to a WCS release:

projects\Releases\WCS\WMS\Release%20ZIPs|\\spekefs2012\projects\Releases\WCS\WMS\Release ZIPs

Contains the ZIP files which are copied to the sites and released.

projects\Releases\WCS\WMS\Release%20Notes|\\spekefs2012\projects\Releases\WCS\WMS\Release Notes

Contains release notes with details of the changes made inside each release.

projects\Releases\WCS\WMS|\\spekefs2012\projects\Releases\WCS\WMS

Contains sent emails of Release Notes generated from the XLS

projects\Releases\WCS\WMS\Release%20DBs|\\spekefs2012\projects\Releases\WCS\WMS\Release DBs

Contains backup versions of the rdt1 and log databases

Note: These Dir's also exist for TMS, replacing WMS with TMS.

Release Procedure

Identify the required zip/package

Check the Release XLS to find the requested Supimix references and cross reference this with the current T/L row for the client to see if the client requires a release. Check all Supimix references and make a note of the highest i.e. the latest package that contains all the required references.

NOTE: If the UPxxx package is in red text in the spreadsheet, then it means a significant bug has been found in that release and it should not be released - in this instance, use the next non-red package where this would have been fixed.

Make a note of both the current ZIP version and the version to be released.

Check if Log database release required.

projects\\product\\WCS\\All Projects\\Support|\\spekefs2012\projects\RDT\All Projects\Support]]

Note that this document is password protected.

For most clients with OBS hosted systems, copying the ZIP to site will simply be a copy/paste onto an RDP session. The RDP's can be found in:

[[file:///\\spekefs2012\projects\Releases\WCS\RDP's|\\spekefs2012\projects\Releases\WCS\RDP's

For some clients the process is more complex. The process for these sites is also contained within the Home Support document.

The file should be copied into the \Database\Upgrades directory found under the base install directory in the support document, e.g.:

Would mean to copy the ZIP file into:

E:\Program Files\CENWPRD Warehouse Control Server\Database\Upgrades

NOTE: You can shortcut the above procedure if the release is a Test To Live. In this instance you can copy the '.done' file from the Test system into Live and rename it back to '.zip'

\\spekefs2012\projects\Releases\WCS\WMS\Release DBs into the <base>\Database directory

Stop the system

The WCS will be running in an application window, e.g.:

Close the WCS (check you're closing the right one!) by clicking on the X in the corner. You should get prompted for a password:

Enter "password" and click OK, then OK again at the 'Are You Sure' prompt.

If the WCS says 'Connected(x)' as in the above example, it means RDT devices are still connected and you will get an additional prompt:

This is a timer before the system will be taken down. If you want to delay this, enter a figure in minutes; otherwise enter 0 to stop the WCS immediately.

Check for running processes

The quick way to check if processes are still running after shutdown is to check for the existence of an ".ldb" file against either the log (or log1) or rdt1 databases. These can be found in the Database directory underneath the base directory:

If no "ldb" files exist, then it is probably OK to proceed with the release, though it is advised to also do the checks below. If an "ldb" file exists, then the below checks must be done to release the lock - do not just delete the ldb file - it won't work.

Whilst an "ldb" file exists, you will NOT be able to do a successful release.

To ensure none of the files are locked, check WaveLink Studio Administrator (run from the Windows button or desktop shortcut) and check there are no active connections on the relevant Wavelink port - which can be found in the Support Document, e.g. :

Double click on the TCP Connection lines (NOT the TCP Port) and click on Shutdown:

You may find these immediately start again, which could be a problem.

The Windows Task manager also needs to be checked for running instances of the Maintenance or RDT processes. On an RDP session the Windows Task manager can be accessed with the hotkey CTRL-ATL-END and selecting Start Task Manager

In the "Processes" tab, click on the 'Show Processes for All Users' then check the list for RTD processes:

If there are ANY other WCS's running e.g. Live when you have taken down Test for a release, or other clients systems, then you must check which system the RDT is attached to BEFORE killing it. This can be done by right-clicking on each RDT process:

Then checking the File Explorer window that opens - it will open in the base directory of the running RDT, so you will then know if it belongs to the area where you are currently doing the release. If it does, then it can be killed by right-clicking again on the process and selecting End Process. ONLY KILL THE PROCESSES FOR THE SYSTEM YOU ARE UPGRADING

A similar process is also required to look for WCS Maintenance sessions which may also be locking the database:

Release process

BEFORE running the release process, backup the rdt1.mdb database file in the format:

rdt1_<SITE><AREA>_YYYYMMDD.mdb, e.g.:

rdt1_MORL_20190101.mdb

The release process is run by double clicking the WCS_Upgrade_Install SHORTCUT:

Once double-clicked, the process will be as follows - you will get a prompt:

Click OK.

When the release is completed, you will get a second prompt:

If a log database release is required (infrequent) then a further process is required.

Check which log file is in use - it may be called either log or log1 - by looking at the most recent timestamp on the log databases

BEFORE running the database conversion process, backup the log1.mdb (or log.mdb) database file in the format:

log1_<SITE><AREA>_YYYYMMDD.mdb, e.g.:

log1_MORL_20190101.mdb

From the <base>\Database directory double-click the UpdateDB.exe:

Enter the location of the existing log database (in both the Old Database and New Database fields.

Enter the location of the log struct file (copied as part of the 3.3 process) in the New Structure field.

Click on the Update button, and you will get:

Click on OK, and the database will be converted:

When 'Run completed' then just close the Update Database box with the 'X' button.

Restart the System

At this point the release is done and the WCS can be restarted by going into the base directory and double-clicking one of the following dependent on the system type:

The OAQ exe is for Oracle systems, the non-OAQ is for powerhouse.

Release process failures

If the release process fails, then you will get the following prompt:

At this point check the relevant 'failed' log:

For details of the failure, e.g:

Indicating that a process is locking the rdt1 database.

If possible, fix the issue and re-run the release script.

Create Release Note

Once the release is complete, update the Release Spreadsheet for the client/system released, and produce a release note on the 'Reports' tab:

Enter the correct client, Area, System and the From/To zip versions then click on the Release button to create an email:

Send the email to the required recipients and drag/drop the sent email from your sent items into the release emails folder.

Release Rollback

Prior to a roll-back, check that a Rollback.tmp directory exists:

If not, create one.

To roll-back a release, double click on the WCS_Upgrade_Rollback script:

The process is similar to a release:

After the above process, if the log database was converted, then this will have to be reversed using the UpdateDatabase.exe selecting the previous log structure.