...
Table of Contents |
---|
Issue Types
Additions
Issue Type | Reporter | Tracks | Deliverable(s) |
---|---|---|---|
Wish / New Feature |
|
|
|
Requirements |
|
|
|
Epic |
|
|
|
Story |
|
|
|
Alterations
Issue Type | Reporter | Tracks | Deliverable(s) |
---|---|---|---|
Improvement |
|
|
|
Bug |
|
|
|
Accounting
Issue Type | Reporter | Tracks | Deliverable(s) |
---|---|---|---|
Comment |
|
|
|
Processing Request |
|
|
|
Task |
|
|
|
Sub-Task |
|
|
|
Technical Task |
|
|
|
Workflows
Addition Workflows
...
- GitHub: Pull Request(s)
- DockerHub: New Image(s) / Tag(s)
- Confluence: Documentation describing the technical aspects of how the platform fulfills the Use Case
- ???Zephyr: Test Case(s) demonstrating the use case fulfilled by the story
- TODO: discover software for writing test plans
...
- The ticket is marked
IN PROGRESS
and assigned to a developer (referred to hereafter as "the developer") - The developer does the work necessary to enable the use case described in the ticket
- Follow the general development workflows defined above
- Comment on the Story with links / updates to any deliverables that need to be reviewed / tested:
- Pull Requests
- Docker Images
- Documentation
- New JIRA Tickets
- The ticket is marked
IN REVIEW
and assigned to a tester (referred to hereafter as "the tester") - The tester reviews the deliverables of the Story:
- Review any related Pull Requests
- Review any Test Cases / Documentation provided
- Review any new JIRA tickets resulting from the work done
- Pull and run any new Docker images against the Test Cases provided
- The tester needs to Accept, Reject, or Abort the review based on the results
- If the ticket does not contain sufficient information to decide whether or not the deliverables are acceptable, then the tester selects
Review Aborted
- The ticket is marked as
OPEN
and work is stopped on the ticket - The developer adds more detail to the ticket before continuing, for example:
- Test Case
- Passing Conditions
- The developer then returns to #2 #1 above and refines their deliverables
- The ticket is marked as
- If the the deliverables the deliverables are missing, incomplete, or in an untestable state, then the tester selects
Review Rejected
The ticket is marked as
IN PROGRESS
and should then be assigned back to the developer- The developer then returns to #2 #1 above and refines their deliverables
- If the deliverables are tested and in an acceptable form, then the tester selects
Review Accepted
- The ticket is marked as
RESOLVED
- The tester continues the workflow below
- The ticket is marked as
- If the ticket does not contain sufficient information to decide whether or not the deliverables are acceptable, then the tester selects
- The tester merges any outstanding Pull Requests related to this ticket
- The developer switches back to master and syncs with upstream (to pull the new changes into their master branch)
- If applicable, the developer builds and pushes a new "latest" Docker image for the API / UI incorporating the new changes
- The developer selects
CLOSE TICKET
and the ticket is marked asCLOSED
...
- GitHub: Pull Request(s)
- DockerHub: New Image(s) / Tag(s)
- Confluence: Updated technical documentation that reflects any modifications to the platform
- ???Zephyr: Test Case(s) exercising the benefit introduced by this improvement
- TODO: discover software for writing test plans
...
- Ticket Status: Start Progress
- Developer creates a new branch with a small prototype instance containing suggested improvement(s)
- Developer weighs the pros / cons of this solution over the current one against the time it would take to fully implement and test the change
- If not desirable, the developer abandons the branch(es) containing these changes and marks the ticket as CLOSED
- If desirable, the developer completes the modifications on the branch
- Once complete, developer gathers the necessary deliverables:
- Confluence: Create documentation and/or take note of technical details
- GitHub: Create Pull Request(s)
- DockerHub: Create and push a test image tagged with the name of the corresponding git branch
- ???Zephyr: Create new / update existing test cases relating to the modifications
- Ticket Status: Review Ticket and assign to Tester
- Tester reviews / tests any deliverables
- Confluence: Review any relevant documentation or technical details
- GitHub: Review related Pull Request(s)
- DockerHub: Pull and run test image(s) against test cases
- ???Zephyr: Run any new / updated test cases relating to the modifications
- Tester merges any Pull Requests (if applicable)
- Ticket Status: Resolve Ticket and assign back to Developer
- Developer releases other deliverables themselves
- Confluence: Developer migrates any relevant documentation from Personal Space to "National Data Service" public space (if applicable)
- GitHub: Developer syncs with upstream changes (if applicable)
- git checkout master
- git pull upstream master
- git push origin master
- DockerHub: Developer builds and pushes new "latest" stable Docker images
- GitHub: Developer commits and pushes new build date upstream (if applicable)
- Ticket Status: Close Ticket
...
- GitHub: Pull Request(s)
- DockerHub: New Image(s) / Tag(s)
- Confluence: Updated technical documentation that reflects any modifications to the platform
- ???Zephyr: Updated / new Test Case(s) reflecting the expected behavior of the product
- TODO: discover software for writing test plans
...
- Ticket Status: Start Progress
- aside: consider creating a new status for "Verification" stage of Bug tickets?
- Developer reviews affected Use Case(s) and verifies behavioral divergence
- Developer examines validity and may suggest modifications to the Use Case
- Developer determines where the bug stems from in the source
- Developer devises one or more ways to address the bug in question
- Developer selects the "best" option according to their judgement given the circumstances
- Developer fixes product behavior to match expected Use Case
- Once complete, developer gathers any necessary deliverables:
- Confluence: Create documentation and/or take note of technical details
- GitHub: Create Pull Request(s)
- DockerHub: Create and push a test image tagged with the name of the corresponding git branch
- ???Zephyr: Create new / update existing test cases relating to the modifications
- Ticket Status: Review Ticket and assign to Tester
- Tester reviews / tests any deliverables
- Confluence: Review any relevant documentation or technical details
- GitHub: Review related Pull Request(s)
- DockerHub: Pull and run test image(s) against test cases
- ???Zephyr: Run any new / updated test cases relating to the modifications
- Tester merges any Pull Requests (if applicable)
- Ticket Status: Resolve Ticket and assign back to Developer
- Developer releases other deliverables themselves
- Confluence: Developer migrates any relevant documentation from Personal Space to "National Data Service" public space (if applicable)
- GitHub: Developer first syncs with upstream changes (if applicable)
- git checkout master
- git pull upstream master
- git push origin master
- DockerHub: Developer builds and pushes new "latest" stable Docker images
- GitHub: Developer commits and pushes new build date upstream (if applicable)
- Ticket Status: Close Ticket
...
These issue types outline non-development tasks or support requests related to the platform.
- Comment: track miscellaneous information / feedback / requests that do not match other issue typesIssue Types Used:
- Processing Request: track the creation of new entities in production instance of NDS Labs
- Task: work that is not driven by a new use case. Contains zero or more Sub-Issue tickets
- Technical Task: a small piece of technical work that is not driven by a new use case
- Sub-Task: a small piece of outreach or non-technical work / discussion that is not driven by a new use case
...