...
Date | Responsibility | Action / Deliverables | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DevOps Team | Maintenance screen to be raised in Production once Content Release Lead confirms content cut off is complete (they will request this via "Infra" JIRA 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) | ||||||||||
DevOps Team | Termserver branching and Release versioning (DevOps to raise tickets themselves as per Terance's request): | |||||||||||
| WCI (External Team) | 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) | ||||||||||
| DevOps 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 | ||||||||||
- | DevOps Team | Once Release Manager sends proposed Beta release package:
| ||||||||||
| DevOps Team | Once the final Beta release is published, re-start the mapping Drip Feed - this can actually be done earlier than the final Beta if required, as the only pre-requisite is to complete the ICD-0/ICD-10 testing in the Beta build. This is simply to provide confidence that it's unlikely that we'll need to make map changes during the 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 Beta build to switch the drip feed back on. | ||||||||||
| DevOps 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 Beta fixes have been applied correctly, & haven't had any adverse impacts. | |||||||||||
| DevOps 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. | ||||||||||
| DevOps 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 Team | 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 Team | Once Release Manager confirms Production release is published:
| |||||||||||
| DevOps 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 |
...