About This Document
This document should be referenced and used for performing product updates. This document covers key steps to be understood and prepared based on our internal technical procedure. It also contains information about roll-back procedures.
Concurrent "Non-Stop" Upgrade with Backwards Compliant Schema Changes
This type of change can be made to the server and both the existing and the new version of workstation should function normally. It may break some non-critical parts of the existing workstation.
| Phase|| Timing||Downtime|| Work Description|
| Prep||1 ore more days prior||less than a minute||Upload the product installation material to the servers and prepare workstation installer download area (Imorgon).|
Designate a test workstation, and ready it to install new version (Customer and Imorgon).
Fail-over the server and make sure all the workstations can access the server without a problem. If there is a problem correct the workstation configuration.
Fail-back to normal production.
|DB Update||1 day prior to product update||less than a minute||Stop all services. Note the exact date and time for roll back purposes.|
Backup Database, Apply Schema Changes, Test Existing Workstation Functionality.
|Update Secondary||Day of update||less than a minute||Backup current installation, install new version on the Mirror, manually start services from the new version then start them as services.|
Fail-over the server to the Secondary server.
Upgrade the test workstation, point it to the secondary server. Check with the customer for functionality.
|Go/NoGo|| || ||=== GO/NO-GO DECISION ===|
If everything is fine then we can move on to next step, otherwise rollback.
|Update Primary|| ||less than a minute||Update the software version of the primary|
Fail-Back the Principal to the Primary
| || || || |
This process may incur up to 30 minutes to an hour of downtime while we back-out the schema changes.
- If the database schema is acceptable but the server software is causing the issue, we can also do software-only rollback by skipping the DB rollback step.
- Back out all of the fields added in the schema change
- Fail back the services to the Primary Server
- Perform Software Rollback on the Seondary