-
Notifications
You must be signed in to change notification settings - Fork 0
Deployment Lessons
Raymond Rusk edited this page Nov 21, 2013
·
4 revisions
This wiki page outlines the lessons learned when deploying to our first alpha site.
Actors | Pre-Deployment | Deployment | Post-Deployment |
---|---|---|---|
Lab | Deploy as early in the work week as possible, avoiding long weekends and holidays when support from OSP is unavailable. Best to have at least 2-3 days left in the week when OSP support will be available if needed. | ||
Have staff available outside of regular working hours. May be difficult to work remotely while site's network is active. | Have staff available outside of regular working hours. May be difficult to work remotely while site's network is active. | ||
Make sure deployment staff have good network connectivity to scoophub. This means that they should probably not be at the clinic but in a location with good connectivity to the hub, good monitors, etc. Not the clinic server room where it might be hard to get an outside network connection to UVic. | Make sure deployment staff have good network connectivity to scoophub. This means that they should probably not be at the clinic but in a location with good connectivity to the hub, good monitors, etc. Not the clinic server room where it might be hard to get an outside network connection to UVic. | ||
Be sure to update Endpoint Oscar just before shipping to clinic and again before starting it up if changes have been made. Was a problem for Bayswater since the installed version of Endpoint Oscar needed updates. | Update query-gateway if necessary when deployed. Wasn't necessary for Bayswater but could be an issue if the endpoint is in transit for an extended period before deployment or we are making frequent code updates. | ||
Have a suite of Data Quality SQL queries to diagnose problems seen during the E2E export/import | Make sure that there is a root cronjob to restart autossh before deploying the server. (Not a problem for Bayswater since I made sure there was. Don't know whether the network has been sufficiently unstable that it was needed but it is there if needed.) | ||
OSP | Confirm availability of OSP during installation | Re-confirm availability of OSP during installation | |
Confirm no practice OSCAR updates are occurring at the same time as the SCOOP node deployment | Re-confirm no practice OSCAR updates are occurring at the same time as the SCOOP node deployment | ||
Clinic | Confirm no practice OSCAR updates are occurring at the same time as the SCOOP node deployment | ||
Have clinic indicate any outstanding service request issues relating to Network, Servers, and OSCAR / back up. | Have clinic indicate any outstanding service request issues relating to Network, Servers, and OSCAR / back up. | ||
Ask clinic for number of active patients so we know how many E2E records to expect. |
SCOOP is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
- SCOOP Overall Design
- SCOOP Actors
- User Stories and Use Case Maps
- System Architecture
- Development Process
- Prototypical Questions
- Current Meds vs Med List
- Data Enrichment Design
- Data Visualization
- Deployment Architecture
- EMR-2-EMR (E2E)
- OSCAR Setup
- Gateway & Hub Setup
- OSCAR Development Notes
- OSCAR DB Table Notes
- Coding Standards
- Mongodb Notes
- Server Configuration
- PDC Gateway Server
- Iteration Overview
- Feature List
- Architecture
- Requirements
- Visualization Requirements
- Test Specification