...
Date | Responsibility | Action / Deliverables | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Infrastructure Team | Maintenance screen to be raised in Production once Content Release Lead confirms content cut off is complete (they will request this via Infra ticket) | ||||||||||||
| Development Team | Check that inferred relationship coming from Snomed Release Service match those in Snowstorm to avoid large and unnecessary data reconciliation effort. | ||||||||||||
| Development Team | Traceability content verification - Checks to be completed in order to ensure that there are no concepts in the termserver that were promoted by the authors, but yet somehow didn’t make it into MAIN ready for versioning (as has happened before) | |||||||||||||
| Infrastructure Team | Termserver branching and Release versioning: | ||||||||||||
| WCI | Once the mapping team have finalised the maps, update the Mapping Drip feed (DevOps to raise JIRA ticket for WCI under the parent Release ticket) | ||||||||||||
| Infrastructure Team | Provisional date to drop Maintenance screen and re-open Content authoring for next editing cycle - UPDATE DATE IN FUTURE IF WE DECIDE WE CAN LET THE AUTHORS BACK IN EARLY | ||||||||||||
| Infrastructure Team | Once Release Manager sends proposed Alpha release package, run the test upload into Dev browser to ensure no issues. | ||||||||||||
| Infrastructure Team | Once the final Alpha release is published, re-start the mapping Drip Feed - this can actually be done earlier than the final Alpha if required, as the only pre-requisite is to complete the ICD-0/ICD-10 testing in the Alpha build. This is simply to provide confidence that it's unlikely that we'll need to make map changes during the Alpha/Beta stage, which could in theory create re-work for the teams. This risk should be balanced against the growing backlog of map changes, and a decision made whether to use an early Alpha build to switch the drip feed back on. | ||||||||||||
| Infrastructure Team | Create a new, separate instance of the Dev browser with the provisional Beta release package as a baseline. This is to allow the Content Team to verify that all of the Alpha fixes have been applied correctly, & haven't had any adverse impacts. | |||||||||||||
| Infrastructure Team | Once Release Manager sends proposed Beta release package, run the test upload into Dev browser to ensure no issues. First recreate dev from prod data so version does not already exist. | ||||||||||||
| Infrastructure Team | Create a new, separate version of the Dev browser with the provisional Member release package as a baseline. This is to allow the Content Team to verify that all of the Alpha + Beta fixes have been applied correctly, & haven't had any adverse impacts. | |||||||||||||
| Devops | Enable Feedback fix project promotion and promote (will go to release branch) | ||||||||||||
| Development Team | Once Release Manager confirms Production release is published, update both the
Check this through with Peter as likely unnecessary now with new reports... | ||||||||||||
| Development Team to pair with DevOps | Once Release Manager confirms Production release is published:
| ||||||||||||
| Infrastructure Team | Once Release Manager confirms Production release is published, update all Production systems (authoring platform, browser) using the final S3 published package. From September 2020 ensure that the GPS ValueSet is available through the FHIR API ie https://browser.ihtsdotools.org/fhir/ValueSet/gps |
...