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 |
Run MRCM Validator manually, in order to verify MRCM Refsets themselves (content is now automatically validated against the MRCM as part of RVF). Run the dailybuild locally and no issues found. MAINT-1297 has merged the refset validations and will be released in 6.7
| 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: |
|
| 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 Alpha release package |
:
|
|
|
|
| DevOps 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. | |
| 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 Alpha 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. |
Once Release Manager confirms Production release is deployed to S3, RVF auto-scaling images to be rebuilt
please confirm new SnowStorm process - is this still required?
It no longer requires an AMI update for new Snomed releases. Please remove this step in future releases.
| 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. |
|
Development Team
Merge all Alpha/Beta fixes into the original Release branch
OLD PROCESS (Kai Kewley / Michael Chu please confirm new SnowStorm process?):
Export Release feedback fixes from main/RFJ branch
Import Release feedback fixes into the MAIN/[release date]/[fix branch]
Promote Fix branch to Release branch for Release Manager to run Production release build
Build and test Production release
a) If all clean then use the new Release branch for final Production Public release
b) If major issues then revert back to Fix branch for final Production Public releaseXXX AMI update no longer required XXX
Dev-Ops create a new Snapshot export from MAIN/[release date] in Prod termServer
Dev-Ops update the classification service using the snapshot export
Compare release fixes with MAIN delta export to create a consolidated RF2 delta
Import RF2 delta into MAIN/[release date]/[fix branch]
Run classifications and validation before promoting MAIN/[release date]/[fix branch] into MAIN
Andrew Atkinson I don't think these steps are the old process either. e.g We can't promote MAIN/[release date]/[fix branch] into MAIN. Please ignore these. I will have a chat with Kai Kewley to document the new process as he did all the work in the last release.
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 |