Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

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.

Traceability

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. In this way, all content associated with a project branch and project-task branches is associated with the identifier of the JIRA project in terms of which content is being edited. Thus, content that is released can be traced back to the request (also associated with authors). 

Workflow

There are two levels of workflow. Both are managed in JIRA.

  1. Project workflow, which applies to the request as a whole as it progresses through the phases of the content development workflow. The diagram here applies to project workflow.
  2. Task workflow, which applies to content that is authored, validated and reviewed. The diagram opposite applies to task workflow.   

Workflow states can be defined as necessary in JIRA, and managed according to the flow required on a per project basis. The authoring team would control these. Therefore the diagram shows only examples where workflow states might transition. When implemented, the workflow states will likely be different to those shown here. 

 

 

 

  • No labels