The diagram opposite describes how the branching strategy will relate to work flow and workflow states. The perspective on workflow and the relationship between the terminology server and JIRA will evolve as the details of the implementation become known.
Branching
The release candidate branch is a permanent branch. When a content project is identified, a project branch is created in the terminology server (TS). Content is not edited directly on the project branch. When content is edited or created, a task branch is created in the TS. Content edits are associated with the task branch. When tasks are completed the content created and edited for the task is merged back to the project branch. When projects are completed the project content is merged onto the release candidate branch. The release candidate is exported periodically (e.g. daily) and content that was created since the previous export is sent to the release and release validation services.
Workflow
When a content project is identified, a JIRA project is created, and the JIRA project identifier associated with the TS project branch. Task branches are associated with the same project identifiers, or identifiers of sub-projects.
All content edited for a given project
When a content project is identified, a ticket (project) is created in JIRA, and a corresponding branch is created, from the release candidate branch, in the terminology server (TS).
The project ID in JIRA is associated with the project branch in the TS.
All SNOMED CT components that are created and edited as part of the project are associated with the project branch, and therefore traceable back to the JIRA ticket.
Workflow state is managed in JIRA. Applications that need to know the workflow state of a project at any time, use the JIRA API to look it up in JIRA.
SNOMED CT content is created and edited on task branches, which are derived from project branches.
