Page tree
Skip to end of metadata
Go to start of metadata

Once a new International release has been published, members can request an "Upgrade" to allow their extension to use the latest International Edition. This page describes the steps needed to complete the upgarde process.


The assumption is that

The old INTL Branch is : MAIN/2016-01-31

The new INTL Branch is: MAIN/2016-07-31


  1. Run a backup. Or check you have last night's backup (depends on if there has been any work since last backup).

  2. You will need to migrate extension relationships  for EACH & EVERY extension in the MS instance. 
    This may need to be done in advance of the switch as the fixes may have to be made/agreed to by the extension owners
  3. You may have to do a release. May/Will need the release team as versioning = releasing. This will reset the effectiveDate/TIme 
    so prior thought needs to be given. Does allow for a roll back to the state the instance is in now and will check module dependencies.
    IF the decision is take to version then:
    Version the existing branch via this end point :!/code-system-metadata/createVersion
    example  json: 
      "version": "2016-06-30",
      "description": "Version prior to moving to the 2016-07-31 International release",
      "effectiveDate": "20160630"
  4. Create a new Branch using this endpoint!/branches/createBranch
    The 2 values that will need changing from the ones used before for this extension will be :
    Meta data: "dependencyRelease":"20160731" and main part: "parent": "MAIN/2016-07-31"

    The dependency release should be set to the new INTL one and the parent to the new INTL branch.

    The previous release should be set to the the last "official" release of the codesystem in the RVF/Orchestration Service (which thus will probably not need to change) e.g. "previousRelease":"20160630". 

    "metadata": {
    "assertionGroupNames": "common-authoring,se-authoring",
    "defaultModuleId": "45991000052106",
    "defaultNamespace": "1000052",
    "": "46011000052107"
    "parent": "MAIN/2017-01-31",
    "name": "SNOMEDCT-SE"

  5. Then merge the old into the new NOTE: The source branch MUST NOT be in a diverged state. If it is then it must be rebased etc.
    Use this end point :!/branches/createMerge

    Create the following JSON

    "source": "MAIN/2016-01-31/SNOMEDCT-SE",
    "target": "MAIN/2016-07-31/SNOMEDCT-SE",
    "commitComment": "Upgraded SE release to 2016-07-31 INT."
    Where the source is the old extension branch, the target is the new extension branch and the comment is a comment of your choosing.

  6. Leave it to run..... it will take some time... the response to the action above will include a url such as
    Which will tell you the state etc of what is going on and eventually will tell you if there were any failures / conflicts etc.etc.
    NOTE: The merge log is volatile and will not survive a restart of the termserver. ergo make sure that you keep the log separately if needed.
    NOTE: If running over night..... REMEMBER to turn off any backup jobs as they will interfere!
  7. Once updated with no conflicts..... update the code system to point to the new path as base
  8. Create the following JSON (adjusting the values obviously). You will need the exsting oid or shortname of the code system
    Quick way to get this is if the CS already exists use the list all codesystems link above the update one and find the oid/shortname

    "repositoryUuid": "snomedStore",
    "branchPath": "MAIN/2016-07-31/SNOMEDCT-SE"

  9. Update the mrcm rules on the newly created branch and remember to rebase it.
    To rebase via the rest api (vs using the UI)  do a merge from main to the branch e.g.!/branches/createMerge

    "source": "MAIN/2016-07-31",
    "target": "MAIN/2016-07-31/SNOMEDCT-SE",
    "commitComment": "Rebasing SE release 2016-07-31 INT."

  10. You will need to add the extension to the rvf and then create a new ami instance to use it & then switch the rvf to use the new ami
    In case you have forgotten... the branch "previousRelease" value needs to be updated to point to this new release via!/branches/updateBranch as this is what is used to direct the code to the relevant release in rvf.
  11. Update the extensionBase field of the JIRA (Workflow) project "magic tickets" to point at the upgraded Extension Mainline branch.
    1. Each Project will have a "Magic Ticket" which controls the metadata for that project. This ticket ID is always "1" i.e.  DKMARB-1 - Getting issue details... STATUS
      1. Details on how these magic tickets are configured for a new project are located HERE
    2. Go to the magic ticket for the project that has been upgraded find the "Magic Ticket" and change the "Extension Base" field to the new upgraded branch
      i.e. MAIN/2016-07-31/SNOMEDCT-DK (Old) → MAIN/2017-01-31/SNOMEDCT-DK (New)
    3. Save changes and then log into the authoring platform and create a new task on that project to initialise the branch.
    4. This "initialisation" task can be deleted later after testing classification and validation.

  12. If there is a daily build to browser job configured for the extension remember to update the branch it uses to export from to build.
    As an example the Swedish extension has an initial build job :
    If you configure it you will see an "Execute shell" within which is a curl post within which are some settings such as: 
    {"productName":"SNOMED CT SE Daily Build","effective-date":"20170531", "exportType":"UNPUBLISHED","branchPath":"MAIN/2017-01-31/SNOMEDCT-SE","releaseCenter":"se"}
    The 2 settings above which will need to be checked are: "branchPath" and "effective-date"
  13. There will then be a RF2 to JSON job such as: . Again if you go to configure you will see that it calls an ansible play in this case
    called daily-build-browser-json-conversion-local-se.yml. You will have to check that for the "unpacked_release_file_name" .
  • No labels