Page History

...

• Git Workflows: Forking workflow with feature branches
  1. Fork repo (if applicable)
     • Press "Fork" in GitHub UI
  2. Clone repo to make changes locally (if applicable)
     
     • git clone https://github.com/USERNAME/ndslabs.git
     • git remote add upstream https://github.com/nds-org/ndslabs.git
  3. Ensure correct branch and sync with upstream before making additional changes
     • git checkout master
     • git pull upstream master
  4. Create a branch named after the Story (for example 

     Jira
     server JIRA serverId b14d4ad9-eb00-3a94-88ac-a843fb6fa1ca key NDS-174

     )
     • git checkout -b NDS-174
  5. Make any necessary modifications locally on your branch
  6. Stage any modified files for commit
     • git add path/to/modified/file.ext
  7. Commit any modifications to your local branch with a comment
     • git commit -m "A comment about this commit"
  8. Push any local commits back up to your remote branch (your forked repo)
     • git push origin NDS-174
  9. When you are satisfied with your changesset of commits, create a Pull Request (PR) to view the diff
     • Press "Pull Request" in GitHub UI
     • Be sure to select the correct base and compare branches
       • Select nds-org/ndslabs as the base fork
       • Select master as the base branch
       • Select your personal fork (USERNAME/ndslabs) as the head fork
       • Select your personal Story branch as the compare branch
     • Scroll down and click on the "Files Changed" tab to briefly review your own Pull Request
       • Ensure that all changes made on this branch were intentional
       • If you are unsure about any specific code segments, comment in-line on the PR to ask for clarification
       • If you are unsure about any general concepts changed or introduced, comment in the section at the bottom of the PR
     • Name your Pull Request after the Story / branch (i.e. "NDS-174: User can access console of running service via CLI") 
     • Enter a short description of any modifications, additions, or removals from the codebase
       • If applicable, include a Test Case that the reviewer should run before merging the Pull Request
     • Click "Create Pull Request"
• Docker Workflows: Upload any necessary test images to Docker Hub
  1. Build test image
     • docker build -t ndslabs/apiserver:dev .
  2. Tag test image with Story id (i.e. NDS-174)
     • docker tag ndslabs/apiserver:dev ndslabs/apiserver:NDS-174
  3. Push test image to Docker Hub
     
     • docker push ndslabs/apiserver:NDS-174
• Kubernetes Workflows: Sometimes used in testing new services or the API server

...

To handle issue and project tracking we use JIRA, which currently offers several different Issue Types when creating new tickets.

The expected usage of expectations arising from each Issue Type is are outlined briefly in the workflows below:.

Addition Workflows

Issue Types Used:

• Wish / New Feature: a high-level non-technical description of desired business logic
• RequirementsRequirement: a "discussion" ticket describing a new feature that needs more of its technical description fleshed out
• Epic: a high-level technical description of desired software functionality or infrastructure containing multiple Story tickets
  
  • Note: Epic issues do not get explicitly added to Sprint
• Story: a use case describing an example usage of a small piece of newly desired functionality

...

1. A New Feature or Wish ticket is filed describing the new feature at a high-level without mandating any particular technical specifications
2. A Requirements ticket is created if we do not have enough information to break the feature down into small pieces of technical work
3. A Story ticket is filed from the information resulting from the Requirements discussionRequirement discussion
   
   1. If multiple Story tickets encompass the work needed, these tickets are grouped under an over-arching Epic ticket

...

1. The ticket is marked IN PROGRESS and assigned to a developer, who conducts the meeting
2. The feature is broken down into a digestable number of enumerated use cases
3. If one or more use cases require more detail, a RequirementsRequirement ticket is filed
4. The use cases are filed as Story tickets and associated to an Epic
5. The resulting Story tickets are then discussed at the next Sprint Planning meeting

...

Requirements Workflow

When a RequirementsRequirement ticket is in the Active Sprint:

...

• Pull Request(s) to GitHub
• New Image(s) / Tag(s) in Docker Hub
• Test Case(s) demonstrating the use case fulfilled by the story
• Documentation describing the technical aspects of the solution

...

Alteration Workflows

...

Issue Types Used:

• Improvement: a suggestion to utilize new techniques or technologies to improve overall performance or maintainability of the platform

• Bug

...

• :

...

• Bug: a previously completed use case or edge case that is malfunctioning according to its defined behavior

Miscellaneous Workflows

Task Workflow

...

Possible Stages:

1. A Bug or Improvement ticket is filed detailing a potential modification that will have a positive impact on the platform
2. If necessary, a Requirement ticket is filed to explore the ramifications of the changes

Improvement Workflow

Bug Workflow

Accounting Workflows

Issue Types Used:

• Processing Request: track the creation of new entities in production instance of NDS Labs
• Comment: track miscellaneous information / feedback / requests that do not match other issue types.
• Task: work that is not driven by a new use case containing zero or more Sub-Issue tickets (i.e. collaboration with other teams)
  • 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

Task Workflow

Used to Track:

1. events requiring special attention (i.e. hackathon, developer tutorial, etc.)

Comment Workflow

Issue Types Used :

• Comment: track miscellaneous information / feedback / requests that do not match other issue types:

Used to Track:

1. new sites / groups / contacts wishing to utilize the NDS Labs platform (i.e. Odum, TACC, SDSC, etc.)
2. similar technologies that we might look at for reference (i.e. JujuCharms, ProfitBricks, etc.)
3. new or existing technologies that might be leveraged to further NDS Labs

Request Workflow

Issue Types Used:

...

Used To Track:

1. projects (via Account Creation Workflow)
2. service specs (via Pull Requests made to ndslabs-specs)